#
b34ce311 |
|
05-Apr-2024 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate duplicate runtime section definitions The following symbols are defined in two includes: * __efi_runtime_start[] * __efi_runtime_stop[] * __efi_runtime_rel_start[] * __efi_runtime_rel_stop[] Eliminate the definitions in efi_loader.h. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
c1624846 |
|
04-Apr-2024 |
Ilias Apalodimas <ilias.apalodimas@linaro.org> |
efi_loader: access __efi_runtime_start/stop without & A symbol defined in a linker script (e.g. __efi_runtime_start = .;) is only a symbol, not a variable and should not be dereferenced. The common practice is either define it as extern uint32_t __efi_runtime_start or extern char __efi_runtime_start[] and access it as &__efi_runtime_start or __efi_runtime_start respectively. So let's access it properly since we define it as an array Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
c38cb227 |
|
14-Dec-2023 |
Tom Rini <trini@konsulko.com> |
efi_loader: Remove <common.h> We largely do not need <common.h> in these files, so drop it. The only exception here is that efi_freestanding.c needs <linux/types.h> and had been getting that via <common.h>. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
b571b3ac |
|
13-Aug-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix efi_add_known_memory() In efi_add_known_memory() we currently call board_get_usable_ram_top() with an incorrect value 0 of parameter total_size. This leads to an incorrect value for ram_top depending on the code in board_get_usable_ram_top(). Use the value of gd->ram_top instead which is set before relocation by calling board_get_usable_ram_top(). Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ecae4bbf |
|
29-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: memory leak efi_add_memory_map_pg Don't leak newlist if we error out. Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
257a498f |
|
29-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of memory in efi_mem_carve_out Handle out of memory situation in efi_mem_carve_out(). Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
48d183f2 |
|
30-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: overflow in efi_allocate_pages On 32bit systems (pages << EFI_PAGE_SHIFT) may lead to an overflow which does not occur in 64bit arithmetics. An overflow of (pages << EFI_PAGE_SHIFT) on 64bit systems should be treated as an error. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ba275630 |
|
29-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of memory in efi_add_memory_map_pg Handle out of memory situation in efi_add_memory_map_pg(). Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
207b6864 |
|
05-Apr-2023 |
Bin Meng <bmeng@tinylab.org> |
efi: loader: Make efi_mem static efi_mem is only referenced in efi_memory.c Signed-off-by: Bin Meng <bmeng@tinylab.org> |
#
f606fab8 |
|
19-Mar-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: move dp_alloc() to efi_alloc() The incumbent function efi_alloc() is unused. Replace dp_alloc() by a new function efi_alloc() that we can use more widely. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
0763c02e |
|
07-Jan-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix description of memory functions * Add missing function descriptions * Adjust to Sphinx style Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
eff44401 |
|
05-Jan-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: carve out efi_get_memory_map_alloc() Carve out code from efidebug command used to read the memory map. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
1a127962 |
|
29-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: don't use EFI_LOADER_DATA internally EFI_LOADER_DATA/CODE is reserved for EFI applications. Memory allocated by U-Boot for internal usage should be EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE. Reported-by: François-Frédéric Ozog <ff@ozog.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: François-Frédéric Ozog <ff@ozog.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
53def68d |
|
05-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAddress requires page address AllocatePages() can be called with Type=AllocateAddress. Such a call can only succeed if *Memory points to the address of an unallocated page range. A call with *Memory being an address that is not page aligned must not succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES if the requested pages cannot be allocated. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
8da26f51 |
|
25-Apr-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_add_conventional_memory_map() Remove redundant constraint. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ebdea88d |
|
11-Oct-2021 |
Ilias Apalodimas <ilias.apalodimas@linaro.org> |
efi_loader: Fix loaded image alignment We are ignoring the alignment communicated via the PE/COFF header. Starting 5.10 the Linux kernel will loudly complain about it. For more details look at [1] (in linux kernel). So add a function that can allocate aligned EFI memory and use it for our relocated loaded image. [1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Vincent Stehlé <vincent.stehle@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
49d225e7 |
|
17-Aug-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use correct type for AllocatePages, AllocatePool Use enum efi_memory_type and enum_allocate_type in the definitions of the efi_allocate_pages(), efi_allocate_pool(). In the external UEFI API leave the type as int as the UEFI specification explicitely requires that enums use a 32bit type. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il> |
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b05667c |
|
16-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Merge memory map entries We currently do not combine memory entries that are adjacent and have the same attributes. The problem with that is that our memory map can easily grow multiple hundreds of entries in a simple UEFI Shell environment. So let's make sure we always combine all entries to make the memory map as small as possible. That way every other piece of code that loops through it should also gain some nice speed ups. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
14deb5e6 |
|
30-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "Revert "efi_loader: efi_allocate_pages is too restrictive"" This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710. Now that the underlying issue is fixed, we can revert the revert and hence restore the original EFI code. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <masahiroy@kernel.org> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
9b89183b |
|
14-Jul-2018 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
efi: Fix truncation of constant value Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"), sparse constantly complains about truncated constant value in efi.h: include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0) This can get quite noisy, preventing real issues to be noticed: $ make defconfig *** Default configuration is based on 'sandbox_defconfig' $ make C=2 -j12 2>&1 | grep truncates | wc -l 441 After the patch is applied: $ make C=2 -j12 2>&1 | grep truncates | wc -l 0 $ sparse --version v0.5.2 Following the suggestion of Heinrich Schuchardt, instead of only fixing the root-cause, I replaced the whole enum of _SHIFT values by ULL defines. This matches both the UEFI 2.7 spec and the Linux kernel implementation. Some ELF size comparison before and after the patch (gcc 7.3.0): efi-x86_payload64_defconfig: text data bss dec hex filename 407174 29432 278676 715282 aea12 u-boot.old 407152 29464 278676 715292 aea1c u-boot.new -22 +32 0 +10 efi-x86_payload32_defconfig: text data bss dec hex filename 447075 30308 280076 757459 b8ed3 u-boot.old 447053 30340 280076 757469 b8edd u-boot.new -22 +32 0 +10 Fixes: 867a6ac86dd8 ("efi: Add start-up library code") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
fa995d0d |
|
06-Aug-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid NULL dereference in efi_get_memory_map() We should only dereference parameter memory_map_size after checking that it is valid. Fixes: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ccfc78b8 |
|
02-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "efi_loader: efi_allocate_pages is too restrictive" This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for example when running test/py. Reverting this change isn't optimal, but at least restores TX1 to a working state. In the future, we should: a) Fix whatever problem causes the crash with this patch applied. This needs further discussion, so isn't something we can immediately do. b) Undo the revert; re-apply the original patch to efi_allocate_pages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1fcb7ea2 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check map_key in ExitBootServices The UEFI spec requires that the memory map key is checked in ExitBootServices(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
8e835554 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters of GetMemoryMap Check the parameters of boottime service GetMemoryMap(). Return EFI_INVALID_PARAMETER where required by the UEFI spec. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4d5e071e |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters in memory allocation If no pointer is provided throw an error. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
282a06cb |
|
18-Jun-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Expose U-Boot addresses in memory map for sandbox We currently expose host addresses in the EFI memory map. That can be bad if we ever want to use sandbox to boot strap a real kernel, because then the kernel would fetch its memory table from our host virtual address map. But to make that use case work, we would need to have full control over the address space the EFI application sees. So let's expose only U-Boot addresses to the guest until we get to the point of allocation. EFI's allocation functions are fun - they can take U-Boot addresses as input values for hints and return host addresses as allocation results through the same uint64_t * parameter. So we need to be extra careful on what to pass in when. With this patch I am successfully able to run the efi selftest suite as well as grub.efi on aarch64. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
69259b83 |
|
18-Jun-2018 |
Simon Glass <sjg@chromium.org> |
efi: sandbox: Adjust memory usage for sandbox With sandbox the U-Boot code is not mapped into the sandbox memory range so does not need to be excluded when allocating EFI memory. Update the EFI memory init code to take account of that. Signed-off-by: Simon Glass <sjg@chromium.org> [agraf: Remove map_sysmem() call and header reference] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
aa909462 |
|
18-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_allocate_pages is too restrictive When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory. There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: use -1ULL instead] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
32826140 |
|
27-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_mem_carve_out should return s64 efi_mem_carve_out() is used to remove memory pages from a mapping. As the number of pages to be removed is a 64bit type the return type should be 64bit too. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
e09159c8 |
|
26-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid anonymous constants for AllocatePages Do not use anonymous constants when calling efi_allocage_pages. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1f0532ca |
|
27-Apr-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove unnecessary include asm/global_data.h is already included via common.h. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f739fcd8 |
|
07-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert a few files that were missed before As part of the main conversion a few files were missed. These files had additional whitespace after the '*' and before the SPDX tag and my previous regex was too strict. This time I did a grep for all SPDX tags and then filtered out anything that matched the correct styles. Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style") Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bdecaebd |
|
08-Mar-2018 |
Simon Glass <sjg@chromium.org> |
efi: Correct header order in efi_memory The headers are not in the correct order. Fix this. Also drop libfdt_env.h since it is not needed. Signed-off-by: Simon Glass <sjg@chromium.org> Rebased Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7c92fd69 |
|
30-Jan-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use constants in efi_allocate_pages() Using the existing predefined constants is less error prone and makes the code easier to read. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b08c8c48 |
|
04-Mar-2018 |
Masahiro Yamada <masahiroy@kernel.org> |
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h> Thomas reported U-Boot failed to build host tools if libfdt-devel package is installed because tools include libfdt headers from /usr/include/ instead of using internal ones. This commit moves the header code: include/libfdt.h -> include/linux/libfdt.h include/libfdt_env.h -> include/linux/libfdt_env.h and replaces include directives: #include <libfdt.h> -> #include <linux/libfdt.h> #include <libfdt_env.h> -> #include <linux/libfdt_env.h> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
474a6f5a |
|
04-Dec-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: add comments to memory functions Add comments describing memory functions. Fix the formatting of a function declaration. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f5a2a938 |
|
06-Nov-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: consistently use efi_uintn_t in boot services Consistenly use efi_uintn_t wherever the UEFI spec uses UINTN in boot services interfaces. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
946160f3 |
|
13-Sep-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: make pool allocations cacheline aligned This avoids printf() spam about file reads (such as loading an image) into unaligned buffers (and the associated memcpy()). And generally seems like a good idea. Signed-off-by: Rob Clark <robdclark@gmail.com> [agraf: use __aligned] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
a1b24823 |
|
26-Jul-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: fix bug in efi_get_memory_map When booting shim -> fallback -> shim -> grub -> linux the memory map is a bit larger than the size linux passes in on the first call. But in the EFI_BUFFER_TOO_SMALL case we were not passing back the updated size to linux so it would loop forever. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c6e3c3e6 |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: return MapKey efi_get_memory_map should set a defined value for map_key. We later can introduce the test against this value in efi_exit_boot_services as required by the UEFI standard. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
0ecba5db |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: do parameter checks first The parameter checks should be done first. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
71275a3e |
|
14-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: avoid NULL dereference in efi_free_pool If efi_free_pool is called with argument NULL an illegal memory access occurs. So let's check the parameter on entry. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42633745 |
|
06-Mar-2017 |
York Sun <york.sun@nxp.com> |
efi: Add a hook to allow adding memory mapping Instead of adding all memory banks, add a hook so individual SoC/board can has its own implementation. Signed-off-by: York Sun <york.sun@nxp.com> CC: Alexander Graf <agraf@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
511d0b97 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Do not leak memory when unlinking a mapping As soon as a mapping is unlinked from the list, there are no further references to it, so it should be freed. If it not unlinked, update the start address and length. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b6a95172 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Keep memory mapping sorted when splitting an entry The code assumes sorted mappings in descending address order. When splitting a mapping, insert the new part next to the current mapping. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b61d857b |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Readd freed pages to memory pool 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42417bc8 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Track size of pool allocations to allow freeing 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ead1274b |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Move efi_allocate_pool implementation to efi_memory.c 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
bdf5c1b3 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Fix memory map size check to avoid out-of-bounds access The current efi_get_memory_map() function overwrites the map_size property before reading its value. That way the sanity check whether our memory map fits into the given array always succeeds, potentially overwriting arbitrary payload memory. This patch moves the property update write after its sanity check, so that the check actually verifies the correct value. So far this has not triggered any known bugs, but we're better off safe than sorry. If the buffer is to small, the returned memory_map_size indicates the required size to the caller. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
852efbf5 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Update description of internal efi_mem_carve_out In 74c16acce30bb882ad5951829d8dafef8eea564c the return values where changed, but the description was kept. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4c02c11d |
|
05-Sep-2016 |
Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
efi_loader: provide efi_mem_desc version Provide version of struct efi_mem_desc in efi_get_memory_map(). EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines memory descriptor version to 1. Linux kernel also expects descriptor version to be 1 and prints following warning during boot if its not: Unexpected EFI_MEMORY_DESCRIPTOR version 0 Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
#
c933ed94 |
|
16-Jul-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Add debug output for efi_add_memory_map() Tracing the arguments has been helpful for pinpointing overflows. Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
74c16acc |
|
26-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Don't allocate from memory holes When a payload calls our memory allocator with the exact address hint, we happily allocate memory from completely unpopulated regions. Payloads however expect this to only succeed if they would be allocating from free conventional memory. This patch makes the logic behind those checks a bit more obvious and ensures that we always allocate from known good free conventional memory regions if we want to allocate ram. Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
edcef3ba |
|
02-Jun-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Move to normal debug infrastructure 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> |
#
51735ae0 |
|
11-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Add bounce buffer support 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: Alexander Graf <agraf@suse.de> |
#
dede284d |
|
13-Apr-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Handle memory overflows 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> |
#
cee752fa |
|
11-Apr-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
38ce65e1 |
|
30-Mar-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Always allocate the highest available address 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> |
#
5d00995c |
|
03-Mar-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
c1624846 |
|
04-Apr-2024 |
Ilias Apalodimas <ilias.apalodimas@linaro.org> |
efi_loader: access __efi_runtime_start/stop without & A symbol defined in a linker script (e.g. __efi_runtime_start = .;) is only a symbol, not a variable and should not be dereferenced. The common practice is either define it as extern uint32_t __efi_runtime_start or extern char __efi_runtime_start[] and access it as &__efi_runtime_start or __efi_runtime_start respectively. So let's access it properly since we define it as an array Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
c38cb227 |
|
14-Dec-2023 |
Tom Rini <trini@konsulko.com> |
efi_loader: Remove <common.h> We largely do not need <common.h> in these files, so drop it. The only exception here is that efi_freestanding.c needs <linux/types.h> and had been getting that via <common.h>. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
b571b3ac |
|
13-Aug-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix efi_add_known_memory() In efi_add_known_memory() we currently call board_get_usable_ram_top() with an incorrect value 0 of parameter total_size. This leads to an incorrect value for ram_top depending on the code in board_get_usable_ram_top(). Use the value of gd->ram_top instead which is set before relocation by calling board_get_usable_ram_top(). Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ecae4bbf |
|
29-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: memory leak efi_add_memory_map_pg Don't leak newlist if we error out. Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
257a498f |
|
29-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of memory in efi_mem_carve_out Handle out of memory situation in efi_mem_carve_out(). Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
48d183f2 |
|
30-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: overflow in efi_allocate_pages On 32bit systems (pages << EFI_PAGE_SHIFT) may lead to an overflow which does not occur in 64bit arithmetics. An overflow of (pages << EFI_PAGE_SHIFT) on 64bit systems should be treated as an error. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ba275630 |
|
29-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of memory in efi_add_memory_map_pg Handle out of memory situation in efi_add_memory_map_pg(). Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
207b6864 |
|
05-Apr-2023 |
Bin Meng <bmeng@tinylab.org> |
efi: loader: Make efi_mem static efi_mem is only referenced in efi_memory.c Signed-off-by: Bin Meng <bmeng@tinylab.org> |
#
f606fab8 |
|
19-Mar-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: move dp_alloc() to efi_alloc() The incumbent function efi_alloc() is unused. Replace dp_alloc() by a new function efi_alloc() that we can use more widely. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
0763c02e |
|
07-Jan-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix description of memory functions * Add missing function descriptions * Adjust to Sphinx style Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
eff44401 |
|
05-Jan-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: carve out efi_get_memory_map_alloc() Carve out code from efidebug command used to read the memory map. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
1a127962 |
|
29-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: don't use EFI_LOADER_DATA internally EFI_LOADER_DATA/CODE is reserved for EFI applications. Memory allocated by U-Boot for internal usage should be EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE. Reported-by: François-Frédéric Ozog <ff@ozog.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: François-Frédéric Ozog <ff@ozog.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
53def68d |
|
05-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAddress requires page address AllocatePages() can be called with Type=AllocateAddress. Such a call can only succeed if *Memory points to the address of an unallocated page range. A call with *Memory being an address that is not page aligned must not succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES if the requested pages cannot be allocated. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
8da26f51 |
|
25-Apr-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_add_conventional_memory_map() Remove redundant constraint. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ebdea88d |
|
11-Oct-2021 |
Ilias Apalodimas <ilias.apalodimas@linaro.org> |
efi_loader: Fix loaded image alignment We are ignoring the alignment communicated via the PE/COFF header. Starting 5.10 the Linux kernel will loudly complain about it. For more details look at [1] (in linux kernel). So add a function that can allocate aligned EFI memory and use it for our relocated loaded image. [1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Vincent Stehlé <vincent.stehle@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
49d225e7 |
|
17-Aug-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use correct type for AllocatePages, AllocatePool Use enum efi_memory_type and enum_allocate_type in the definitions of the efi_allocate_pages(), efi_allocate_pool(). In the external UEFI API leave the type as int as the UEFI specification explicitely requires that enums use a 32bit type. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il> |
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b05667c |
|
16-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Merge memory map entries We currently do not combine memory entries that are adjacent and have the same attributes. The problem with that is that our memory map can easily grow multiple hundreds of entries in a simple UEFI Shell environment. So let's make sure we always combine all entries to make the memory map as small as possible. That way every other piece of code that loops through it should also gain some nice speed ups. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
14deb5e6 |
|
30-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "Revert "efi_loader: efi_allocate_pages is too restrictive"" This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710. Now that the underlying issue is fixed, we can revert the revert and hence restore the original EFI code. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <masahiroy@kernel.org> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
9b89183b |
|
14-Jul-2018 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
efi: Fix truncation of constant value Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"), sparse constantly complains about truncated constant value in efi.h: include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0) This can get quite noisy, preventing real issues to be noticed: $ make defconfig *** Default configuration is based on 'sandbox_defconfig' $ make C=2 -j12 2>&1 | grep truncates | wc -l 441 After the patch is applied: $ make C=2 -j12 2>&1 | grep truncates | wc -l 0 $ sparse --version v0.5.2 Following the suggestion of Heinrich Schuchardt, instead of only fixing the root-cause, I replaced the whole enum of _SHIFT values by ULL defines. This matches both the UEFI 2.7 spec and the Linux kernel implementation. Some ELF size comparison before and after the patch (gcc 7.3.0): efi-x86_payload64_defconfig: text data bss dec hex filename 407174 29432 278676 715282 aea12 u-boot.old 407152 29464 278676 715292 aea1c u-boot.new -22 +32 0 +10 efi-x86_payload32_defconfig: text data bss dec hex filename 447075 30308 280076 757459 b8ed3 u-boot.old 447053 30340 280076 757469 b8edd u-boot.new -22 +32 0 +10 Fixes: 867a6ac86dd8 ("efi: Add start-up library code") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
fa995d0d |
|
06-Aug-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid NULL dereference in efi_get_memory_map() We should only dereference parameter memory_map_size after checking that it is valid. Fixes: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ccfc78b8 |
|
02-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "efi_loader: efi_allocate_pages is too restrictive" This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for example when running test/py. Reverting this change isn't optimal, but at least restores TX1 to a working state. In the future, we should: a) Fix whatever problem causes the crash with this patch applied. This needs further discussion, so isn't something we can immediately do. b) Undo the revert; re-apply the original patch to efi_allocate_pages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1fcb7ea2 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check map_key in ExitBootServices The UEFI spec requires that the memory map key is checked in ExitBootServices(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
8e835554 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters of GetMemoryMap Check the parameters of boottime service GetMemoryMap(). Return EFI_INVALID_PARAMETER where required by the UEFI spec. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4d5e071e |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters in memory allocation If no pointer is provided throw an error. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
282a06cb |
|
18-Jun-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Expose U-Boot addresses in memory map for sandbox We currently expose host addresses in the EFI memory map. That can be bad if we ever want to use sandbox to boot strap a real kernel, because then the kernel would fetch its memory table from our host virtual address map. But to make that use case work, we would need to have full control over the address space the EFI application sees. So let's expose only U-Boot addresses to the guest until we get to the point of allocation. EFI's allocation functions are fun - they can take U-Boot addresses as input values for hints and return host addresses as allocation results through the same uint64_t * parameter. So we need to be extra careful on what to pass in when. With this patch I am successfully able to run the efi selftest suite as well as grub.efi on aarch64. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
69259b83 |
|
18-Jun-2018 |
Simon Glass <sjg@chromium.org> |
efi: sandbox: Adjust memory usage for sandbox With sandbox the U-Boot code is not mapped into the sandbox memory range so does not need to be excluded when allocating EFI memory. Update the EFI memory init code to take account of that. Signed-off-by: Simon Glass <sjg@chromium.org> [agraf: Remove map_sysmem() call and header reference] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
aa909462 |
|
18-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_allocate_pages is too restrictive When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory. There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: use -1ULL instead] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
32826140 |
|
27-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_mem_carve_out should return s64 efi_mem_carve_out() is used to remove memory pages from a mapping. As the number of pages to be removed is a 64bit type the return type should be 64bit too. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
e09159c8 |
|
26-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid anonymous constants for AllocatePages Do not use anonymous constants when calling efi_allocage_pages. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1f0532ca |
|
27-Apr-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove unnecessary include asm/global_data.h is already included via common.h. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f739fcd8 |
|
07-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert a few files that were missed before As part of the main conversion a few files were missed. These files had additional whitespace after the '*' and before the SPDX tag and my previous regex was too strict. This time I did a grep for all SPDX tags and then filtered out anything that matched the correct styles. Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style") Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bdecaebd |
|
08-Mar-2018 |
Simon Glass <sjg@chromium.org> |
efi: Correct header order in efi_memory The headers are not in the correct order. Fix this. Also drop libfdt_env.h since it is not needed. Signed-off-by: Simon Glass <sjg@chromium.org> Rebased Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7c92fd69 |
|
30-Jan-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use constants in efi_allocate_pages() Using the existing predefined constants is less error prone and makes the code easier to read. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b08c8c48 |
|
04-Mar-2018 |
Masahiro Yamada <masahiroy@kernel.org> |
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h> Thomas reported U-Boot failed to build host tools if libfdt-devel package is installed because tools include libfdt headers from /usr/include/ instead of using internal ones. This commit moves the header code: include/libfdt.h -> include/linux/libfdt.h include/libfdt_env.h -> include/linux/libfdt_env.h and replaces include directives: #include <libfdt.h> -> #include <linux/libfdt.h> #include <libfdt_env.h> -> #include <linux/libfdt_env.h> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
474a6f5a |
|
04-Dec-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: add comments to memory functions Add comments describing memory functions. Fix the formatting of a function declaration. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f5a2a938 |
|
06-Nov-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: consistently use efi_uintn_t in boot services Consistenly use efi_uintn_t wherever the UEFI spec uses UINTN in boot services interfaces. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
946160f3 |
|
13-Sep-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: make pool allocations cacheline aligned This avoids printf() spam about file reads (such as loading an image) into unaligned buffers (and the associated memcpy()). And generally seems like a good idea. Signed-off-by: Rob Clark <robdclark@gmail.com> [agraf: use __aligned] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
a1b24823 |
|
26-Jul-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: fix bug in efi_get_memory_map When booting shim -> fallback -> shim -> grub -> linux the memory map is a bit larger than the size linux passes in on the first call. But in the EFI_BUFFER_TOO_SMALL case we were not passing back the updated size to linux so it would loop forever. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c6e3c3e6 |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: return MapKey efi_get_memory_map should set a defined value for map_key. We later can introduce the test against this value in efi_exit_boot_services as required by the UEFI standard. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
0ecba5db |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: do parameter checks first The parameter checks should be done first. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
71275a3e |
|
14-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: avoid NULL dereference in efi_free_pool If efi_free_pool is called with argument NULL an illegal memory access occurs. So let's check the parameter on entry. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42633745 |
|
06-Mar-2017 |
York Sun <york.sun@nxp.com> |
efi: Add a hook to allow adding memory mapping Instead of adding all memory banks, add a hook so individual SoC/board can has its own implementation. Signed-off-by: York Sun <york.sun@nxp.com> CC: Alexander Graf <agraf@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
511d0b97 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Do not leak memory when unlinking a mapping As soon as a mapping is unlinked from the list, there are no further references to it, so it should be freed. If it not unlinked, update the start address and length. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b6a95172 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Keep memory mapping sorted when splitting an entry The code assumes sorted mappings in descending address order. When splitting a mapping, insert the new part next to the current mapping. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b61d857b |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Readd freed pages to memory pool 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42417bc8 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Track size of pool allocations to allow freeing 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ead1274b |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Move efi_allocate_pool implementation to efi_memory.c 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
bdf5c1b3 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Fix memory map size check to avoid out-of-bounds access The current efi_get_memory_map() function overwrites the map_size property before reading its value. That way the sanity check whether our memory map fits into the given array always succeeds, potentially overwriting arbitrary payload memory. This patch moves the property update write after its sanity check, so that the check actually verifies the correct value. So far this has not triggered any known bugs, but we're better off safe than sorry. If the buffer is to small, the returned memory_map_size indicates the required size to the caller. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
852efbf5 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Update description of internal efi_mem_carve_out In 74c16acce30bb882ad5951829d8dafef8eea564c the return values where changed, but the description was kept. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4c02c11d |
|
05-Sep-2016 |
Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
efi_loader: provide efi_mem_desc version Provide version of struct efi_mem_desc in efi_get_memory_map(). EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines memory descriptor version to 1. Linux kernel also expects descriptor version to be 1 and prints following warning during boot if its not: Unexpected EFI_MEMORY_DESCRIPTOR version 0 Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
#
c933ed94 |
|
16-Jul-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Add debug output for efi_add_memory_map() Tracing the arguments has been helpful for pinpointing overflows. Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
74c16acc |
|
26-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Don't allocate from memory holes When a payload calls our memory allocator with the exact address hint, we happily allocate memory from completely unpopulated regions. Payloads however expect this to only succeed if they would be allocating from free conventional memory. This patch makes the logic behind those checks a bit more obvious and ensures that we always allocate from known good free conventional memory regions if we want to allocate ram. Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
edcef3ba |
|
02-Jun-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Move to normal debug infrastructure 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> |
#
51735ae0 |
|
11-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Add bounce buffer support 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: Alexander Graf <agraf@suse.de> |
#
dede284d |
|
13-Apr-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Handle memory overflows 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> |
#
cee752fa |
|
11-Apr-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
38ce65e1 |
|
30-Mar-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Always allocate the highest available address 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> |
#
5d00995c |
|
03-Mar-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
c38cb227 |
|
14-Dec-2023 |
Tom Rini <trini@konsulko.com> |
efi_loader: Remove <common.h> We largely do not need <common.h> in these files, so drop it. The only exception here is that efi_freestanding.c needs <linux/types.h> and had been getting that via <common.h>. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
b571b3ac |
|
13-Aug-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix efi_add_known_memory() In efi_add_known_memory() we currently call board_get_usable_ram_top() with an incorrect value 0 of parameter total_size. This leads to an incorrect value for ram_top depending on the code in board_get_usable_ram_top(). Use the value of gd->ram_top instead which is set before relocation by calling board_get_usable_ram_top(). Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ecae4bbf |
|
29-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: memory leak efi_add_memory_map_pg Don't leak newlist if we error out. Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
257a498f |
|
29-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of memory in efi_mem_carve_out Handle out of memory situation in efi_mem_carve_out(). Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
48d183f2 |
|
30-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: overflow in efi_allocate_pages On 32bit systems (pages << EFI_PAGE_SHIFT) may lead to an overflow which does not occur in 64bit arithmetics. An overflow of (pages << EFI_PAGE_SHIFT) on 64bit systems should be treated as an error. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ba275630 |
|
29-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of memory in efi_add_memory_map_pg Handle out of memory situation in efi_add_memory_map_pg(). Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
207b6864 |
|
05-Apr-2023 |
Bin Meng <bmeng@tinylab.org> |
efi: loader: Make efi_mem static efi_mem is only referenced in efi_memory.c Signed-off-by: Bin Meng <bmeng@tinylab.org> |
#
f606fab8 |
|
19-Mar-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: move dp_alloc() to efi_alloc() The incumbent function efi_alloc() is unused. Replace dp_alloc() by a new function efi_alloc() that we can use more widely. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
0763c02e |
|
07-Jan-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix description of memory functions * Add missing function descriptions * Adjust to Sphinx style Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
eff44401 |
|
05-Jan-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: carve out efi_get_memory_map_alloc() Carve out code from efidebug command used to read the memory map. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
1a127962 |
|
29-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: don't use EFI_LOADER_DATA internally EFI_LOADER_DATA/CODE is reserved for EFI applications. Memory allocated by U-Boot for internal usage should be EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE. Reported-by: François-Frédéric Ozog <ff@ozog.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: François-Frédéric Ozog <ff@ozog.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
53def68d |
|
05-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAddress requires page address AllocatePages() can be called with Type=AllocateAddress. Such a call can only succeed if *Memory points to the address of an unallocated page range. A call with *Memory being an address that is not page aligned must not succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES if the requested pages cannot be allocated. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
8da26f51 |
|
25-Apr-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_add_conventional_memory_map() Remove redundant constraint. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ebdea88d |
|
11-Oct-2021 |
Ilias Apalodimas <ilias.apalodimas@linaro.org> |
efi_loader: Fix loaded image alignment We are ignoring the alignment communicated via the PE/COFF header. Starting 5.10 the Linux kernel will loudly complain about it. For more details look at [1] (in linux kernel). So add a function that can allocate aligned EFI memory and use it for our relocated loaded image. [1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Vincent Stehlé <vincent.stehle@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
49d225e7 |
|
17-Aug-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use correct type for AllocatePages, AllocatePool Use enum efi_memory_type and enum_allocate_type in the definitions of the efi_allocate_pages(), efi_allocate_pool(). In the external UEFI API leave the type as int as the UEFI specification explicitely requires that enums use a 32bit type. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il> |
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b05667c |
|
16-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Merge memory map entries We currently do not combine memory entries that are adjacent and have the same attributes. The problem with that is that our memory map can easily grow multiple hundreds of entries in a simple UEFI Shell environment. So let's make sure we always combine all entries to make the memory map as small as possible. That way every other piece of code that loops through it should also gain some nice speed ups. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
14deb5e6 |
|
30-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "Revert "efi_loader: efi_allocate_pages is too restrictive"" This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710. Now that the underlying issue is fixed, we can revert the revert and hence restore the original EFI code. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <masahiroy@kernel.org> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
9b89183b |
|
14-Jul-2018 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
efi: Fix truncation of constant value Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"), sparse constantly complains about truncated constant value in efi.h: include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0) This can get quite noisy, preventing real issues to be noticed: $ make defconfig *** Default configuration is based on 'sandbox_defconfig' $ make C=2 -j12 2>&1 | grep truncates | wc -l 441 After the patch is applied: $ make C=2 -j12 2>&1 | grep truncates | wc -l 0 $ sparse --version v0.5.2 Following the suggestion of Heinrich Schuchardt, instead of only fixing the root-cause, I replaced the whole enum of _SHIFT values by ULL defines. This matches both the UEFI 2.7 spec and the Linux kernel implementation. Some ELF size comparison before and after the patch (gcc 7.3.0): efi-x86_payload64_defconfig: text data bss dec hex filename 407174 29432 278676 715282 aea12 u-boot.old 407152 29464 278676 715292 aea1c u-boot.new -22 +32 0 +10 efi-x86_payload32_defconfig: text data bss dec hex filename 447075 30308 280076 757459 b8ed3 u-boot.old 447053 30340 280076 757469 b8edd u-boot.new -22 +32 0 +10 Fixes: 867a6ac86dd8 ("efi: Add start-up library code") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
fa995d0d |
|
06-Aug-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid NULL dereference in efi_get_memory_map() We should only dereference parameter memory_map_size after checking that it is valid. Fixes: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ccfc78b8 |
|
02-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "efi_loader: efi_allocate_pages is too restrictive" This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for example when running test/py. Reverting this change isn't optimal, but at least restores TX1 to a working state. In the future, we should: a) Fix whatever problem causes the crash with this patch applied. This needs further discussion, so isn't something we can immediately do. b) Undo the revert; re-apply the original patch to efi_allocate_pages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1fcb7ea2 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check map_key in ExitBootServices The UEFI spec requires that the memory map key is checked in ExitBootServices(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
8e835554 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters of GetMemoryMap Check the parameters of boottime service GetMemoryMap(). Return EFI_INVALID_PARAMETER where required by the UEFI spec. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4d5e071e |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters in memory allocation If no pointer is provided throw an error. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
282a06cb |
|
18-Jun-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Expose U-Boot addresses in memory map for sandbox We currently expose host addresses in the EFI memory map. That can be bad if we ever want to use sandbox to boot strap a real kernel, because then the kernel would fetch its memory table from our host virtual address map. But to make that use case work, we would need to have full control over the address space the EFI application sees. So let's expose only U-Boot addresses to the guest until we get to the point of allocation. EFI's allocation functions are fun - they can take U-Boot addresses as input values for hints and return host addresses as allocation results through the same uint64_t * parameter. So we need to be extra careful on what to pass in when. With this patch I am successfully able to run the efi selftest suite as well as grub.efi on aarch64. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
69259b83 |
|
18-Jun-2018 |
Simon Glass <sjg@chromium.org> |
efi: sandbox: Adjust memory usage for sandbox With sandbox the U-Boot code is not mapped into the sandbox memory range so does not need to be excluded when allocating EFI memory. Update the EFI memory init code to take account of that. Signed-off-by: Simon Glass <sjg@chromium.org> [agraf: Remove map_sysmem() call and header reference] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
aa909462 |
|
18-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_allocate_pages is too restrictive When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory. There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: use -1ULL instead] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
32826140 |
|
27-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_mem_carve_out should return s64 efi_mem_carve_out() is used to remove memory pages from a mapping. As the number of pages to be removed is a 64bit type the return type should be 64bit too. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
e09159c8 |
|
26-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid anonymous constants for AllocatePages Do not use anonymous constants when calling efi_allocage_pages. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1f0532ca |
|
27-Apr-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove unnecessary include asm/global_data.h is already included via common.h. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f739fcd8 |
|
07-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert a few files that were missed before As part of the main conversion a few files were missed. These files had additional whitespace after the '*' and before the SPDX tag and my previous regex was too strict. This time I did a grep for all SPDX tags and then filtered out anything that matched the correct styles. Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style") Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bdecaebd |
|
08-Mar-2018 |
Simon Glass <sjg@chromium.org> |
efi: Correct header order in efi_memory The headers are not in the correct order. Fix this. Also drop libfdt_env.h since it is not needed. Signed-off-by: Simon Glass <sjg@chromium.org> Rebased Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7c92fd69 |
|
30-Jan-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use constants in efi_allocate_pages() Using the existing predefined constants is less error prone and makes the code easier to read. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b08c8c48 |
|
04-Mar-2018 |
Masahiro Yamada <masahiroy@kernel.org> |
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h> Thomas reported U-Boot failed to build host tools if libfdt-devel package is installed because tools include libfdt headers from /usr/include/ instead of using internal ones. This commit moves the header code: include/libfdt.h -> include/linux/libfdt.h include/libfdt_env.h -> include/linux/libfdt_env.h and replaces include directives: #include <libfdt.h> -> #include <linux/libfdt.h> #include <libfdt_env.h> -> #include <linux/libfdt_env.h> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
474a6f5a |
|
04-Dec-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: add comments to memory functions Add comments describing memory functions. Fix the formatting of a function declaration. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f5a2a938 |
|
06-Nov-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: consistently use efi_uintn_t in boot services Consistenly use efi_uintn_t wherever the UEFI spec uses UINTN in boot services interfaces. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
946160f3 |
|
13-Sep-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: make pool allocations cacheline aligned This avoids printf() spam about file reads (such as loading an image) into unaligned buffers (and the associated memcpy()). And generally seems like a good idea. Signed-off-by: Rob Clark <robdclark@gmail.com> [agraf: use __aligned] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
a1b24823 |
|
26-Jul-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: fix bug in efi_get_memory_map When booting shim -> fallback -> shim -> grub -> linux the memory map is a bit larger than the size linux passes in on the first call. But in the EFI_BUFFER_TOO_SMALL case we were not passing back the updated size to linux so it would loop forever. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c6e3c3e6 |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: return MapKey efi_get_memory_map should set a defined value for map_key. We later can introduce the test against this value in efi_exit_boot_services as required by the UEFI standard. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
0ecba5db |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: do parameter checks first The parameter checks should be done first. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
71275a3e |
|
14-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: avoid NULL dereference in efi_free_pool If efi_free_pool is called with argument NULL an illegal memory access occurs. So let's check the parameter on entry. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42633745 |
|
06-Mar-2017 |
York Sun <york.sun@nxp.com> |
efi: Add a hook to allow adding memory mapping Instead of adding all memory banks, add a hook so individual SoC/board can has its own implementation. Signed-off-by: York Sun <york.sun@nxp.com> CC: Alexander Graf <agraf@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
511d0b97 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Do not leak memory when unlinking a mapping As soon as a mapping is unlinked from the list, there are no further references to it, so it should be freed. If it not unlinked, update the start address and length. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b6a95172 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Keep memory mapping sorted when splitting an entry The code assumes sorted mappings in descending address order. When splitting a mapping, insert the new part next to the current mapping. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b61d857b |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Readd freed pages to memory pool 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42417bc8 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Track size of pool allocations to allow freeing 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ead1274b |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Move efi_allocate_pool implementation to efi_memory.c 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
bdf5c1b3 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Fix memory map size check to avoid out-of-bounds access The current efi_get_memory_map() function overwrites the map_size property before reading its value. That way the sanity check whether our memory map fits into the given array always succeeds, potentially overwriting arbitrary payload memory. This patch moves the property update write after its sanity check, so that the check actually verifies the correct value. So far this has not triggered any known bugs, but we're better off safe than sorry. If the buffer is to small, the returned memory_map_size indicates the required size to the caller. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
852efbf5 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Update description of internal efi_mem_carve_out In 74c16acce30bb882ad5951829d8dafef8eea564c the return values where changed, but the description was kept. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4c02c11d |
|
05-Sep-2016 |
Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
efi_loader: provide efi_mem_desc version Provide version of struct efi_mem_desc in efi_get_memory_map(). EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines memory descriptor version to 1. Linux kernel also expects descriptor version to be 1 and prints following warning during boot if its not: Unexpected EFI_MEMORY_DESCRIPTOR version 0 Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
#
c933ed94 |
|
16-Jul-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Add debug output for efi_add_memory_map() Tracing the arguments has been helpful for pinpointing overflows. Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
74c16acc |
|
26-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Don't allocate from memory holes When a payload calls our memory allocator with the exact address hint, we happily allocate memory from completely unpopulated regions. Payloads however expect this to only succeed if they would be allocating from free conventional memory. This patch makes the logic behind those checks a bit more obvious and ensures that we always allocate from known good free conventional memory regions if we want to allocate ram. Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
edcef3ba |
|
02-Jun-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Move to normal debug infrastructure 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> |
#
51735ae0 |
|
11-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Add bounce buffer support 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: Alexander Graf <agraf@suse.de> |
#
dede284d |
|
13-Apr-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Handle memory overflows 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> |
#
cee752fa |
|
11-Apr-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
38ce65e1 |
|
30-Mar-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Always allocate the highest available address 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> |
#
5d00995c |
|
03-Mar-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
b571b3ac |
|
13-Aug-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix efi_add_known_memory() In efi_add_known_memory() we currently call board_get_usable_ram_top() with an incorrect value 0 of parameter total_size. This leads to an incorrect value for ram_top depending on the code in board_get_usable_ram_top(). Use the value of gd->ram_top instead which is set before relocation by calling board_get_usable_ram_top(). Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ecae4bbf |
|
29-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: memory leak efi_add_memory_map_pg Don't leak newlist if we error out. Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
257a498f |
|
29-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of memory in efi_mem_carve_out Handle out of memory situation in efi_mem_carve_out(). Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
48d183f2 |
|
30-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: overflow in efi_allocate_pages On 32bit systems (pages << EFI_PAGE_SHIFT) may lead to an overflow which does not occur in 64bit arithmetics. An overflow of (pages << EFI_PAGE_SHIFT) on 64bit systems should be treated as an error. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ba275630 |
|
29-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of memory in efi_add_memory_map_pg Handle out of memory situation in efi_add_memory_map_pg(). Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
207b6864 |
|
05-Apr-2023 |
Bin Meng <bmeng@tinylab.org> |
efi: loader: Make efi_mem static efi_mem is only referenced in efi_memory.c Signed-off-by: Bin Meng <bmeng@tinylab.org> |
#
f606fab8 |
|
19-Mar-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: move dp_alloc() to efi_alloc() The incumbent function efi_alloc() is unused. Replace dp_alloc() by a new function efi_alloc() that we can use more widely. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
0763c02e |
|
07-Jan-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix description of memory functions * Add missing function descriptions * Adjust to Sphinx style Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
eff44401 |
|
05-Jan-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: carve out efi_get_memory_map_alloc() Carve out code from efidebug command used to read the memory map. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
1a127962 |
|
29-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: don't use EFI_LOADER_DATA internally EFI_LOADER_DATA/CODE is reserved for EFI applications. Memory allocated by U-Boot for internal usage should be EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE. Reported-by: François-Frédéric Ozog <ff@ozog.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: François-Frédéric Ozog <ff@ozog.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
53def68d |
|
05-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAddress requires page address AllocatePages() can be called with Type=AllocateAddress. Such a call can only succeed if *Memory points to the address of an unallocated page range. A call with *Memory being an address that is not page aligned must not succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES if the requested pages cannot be allocated. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
8da26f51 |
|
25-Apr-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_add_conventional_memory_map() Remove redundant constraint. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ebdea88d |
|
11-Oct-2021 |
Ilias Apalodimas <ilias.apalodimas@linaro.org> |
efi_loader: Fix loaded image alignment We are ignoring the alignment communicated via the PE/COFF header. Starting 5.10 the Linux kernel will loudly complain about it. For more details look at [1] (in linux kernel). So add a function that can allocate aligned EFI memory and use it for our relocated loaded image. [1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Vincent Stehlé <vincent.stehle@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
49d225e7 |
|
17-Aug-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use correct type for AllocatePages, AllocatePool Use enum efi_memory_type and enum_allocate_type in the definitions of the efi_allocate_pages(), efi_allocate_pool(). In the external UEFI API leave the type as int as the UEFI specification explicitely requires that enums use a 32bit type. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il> |
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b05667c |
|
16-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Merge memory map entries We currently do not combine memory entries that are adjacent and have the same attributes. The problem with that is that our memory map can easily grow multiple hundreds of entries in a simple UEFI Shell environment. So let's make sure we always combine all entries to make the memory map as small as possible. That way every other piece of code that loops through it should also gain some nice speed ups. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
14deb5e6 |
|
30-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "Revert "efi_loader: efi_allocate_pages is too restrictive"" This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710. Now that the underlying issue is fixed, we can revert the revert and hence restore the original EFI code. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <masahiroy@kernel.org> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
9b89183b |
|
14-Jul-2018 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
efi: Fix truncation of constant value Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"), sparse constantly complains about truncated constant value in efi.h: include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0) This can get quite noisy, preventing real issues to be noticed: $ make defconfig *** Default configuration is based on 'sandbox_defconfig' $ make C=2 -j12 2>&1 | grep truncates | wc -l 441 After the patch is applied: $ make C=2 -j12 2>&1 | grep truncates | wc -l 0 $ sparse --version v0.5.2 Following the suggestion of Heinrich Schuchardt, instead of only fixing the root-cause, I replaced the whole enum of _SHIFT values by ULL defines. This matches both the UEFI 2.7 spec and the Linux kernel implementation. Some ELF size comparison before and after the patch (gcc 7.3.0): efi-x86_payload64_defconfig: text data bss dec hex filename 407174 29432 278676 715282 aea12 u-boot.old 407152 29464 278676 715292 aea1c u-boot.new -22 +32 0 +10 efi-x86_payload32_defconfig: text data bss dec hex filename 447075 30308 280076 757459 b8ed3 u-boot.old 447053 30340 280076 757469 b8edd u-boot.new -22 +32 0 +10 Fixes: 867a6ac86dd8 ("efi: Add start-up library code") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
fa995d0d |
|
06-Aug-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid NULL dereference in efi_get_memory_map() We should only dereference parameter memory_map_size after checking that it is valid. Fixes: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ccfc78b8 |
|
02-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "efi_loader: efi_allocate_pages is too restrictive" This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for example when running test/py. Reverting this change isn't optimal, but at least restores TX1 to a working state. In the future, we should: a) Fix whatever problem causes the crash with this patch applied. This needs further discussion, so isn't something we can immediately do. b) Undo the revert; re-apply the original patch to efi_allocate_pages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1fcb7ea2 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check map_key in ExitBootServices The UEFI spec requires that the memory map key is checked in ExitBootServices(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
8e835554 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters of GetMemoryMap Check the parameters of boottime service GetMemoryMap(). Return EFI_INVALID_PARAMETER where required by the UEFI spec. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4d5e071e |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters in memory allocation If no pointer is provided throw an error. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
282a06cb |
|
18-Jun-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Expose U-Boot addresses in memory map for sandbox We currently expose host addresses in the EFI memory map. That can be bad if we ever want to use sandbox to boot strap a real kernel, because then the kernel would fetch its memory table from our host virtual address map. But to make that use case work, we would need to have full control over the address space the EFI application sees. So let's expose only U-Boot addresses to the guest until we get to the point of allocation. EFI's allocation functions are fun - they can take U-Boot addresses as input values for hints and return host addresses as allocation results through the same uint64_t * parameter. So we need to be extra careful on what to pass in when. With this patch I am successfully able to run the efi selftest suite as well as grub.efi on aarch64. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
69259b83 |
|
18-Jun-2018 |
Simon Glass <sjg@chromium.org> |
efi: sandbox: Adjust memory usage for sandbox With sandbox the U-Boot code is not mapped into the sandbox memory range so does not need to be excluded when allocating EFI memory. Update the EFI memory init code to take account of that. Signed-off-by: Simon Glass <sjg@chromium.org> [agraf: Remove map_sysmem() call and header reference] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
aa909462 |
|
18-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_allocate_pages is too restrictive When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory. There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: use -1ULL instead] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
32826140 |
|
27-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_mem_carve_out should return s64 efi_mem_carve_out() is used to remove memory pages from a mapping. As the number of pages to be removed is a 64bit type the return type should be 64bit too. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
e09159c8 |
|
26-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid anonymous constants for AllocatePages Do not use anonymous constants when calling efi_allocage_pages. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1f0532ca |
|
27-Apr-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove unnecessary include asm/global_data.h is already included via common.h. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f739fcd8 |
|
07-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert a few files that were missed before As part of the main conversion a few files were missed. These files had additional whitespace after the '*' and before the SPDX tag and my previous regex was too strict. This time I did a grep for all SPDX tags and then filtered out anything that matched the correct styles. Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style") Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bdecaebd |
|
08-Mar-2018 |
Simon Glass <sjg@chromium.org> |
efi: Correct header order in efi_memory The headers are not in the correct order. Fix this. Also drop libfdt_env.h since it is not needed. Signed-off-by: Simon Glass <sjg@chromium.org> Rebased Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7c92fd69 |
|
30-Jan-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use constants in efi_allocate_pages() Using the existing predefined constants is less error prone and makes the code easier to read. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b08c8c48 |
|
04-Mar-2018 |
Masahiro Yamada <masahiroy@kernel.org> |
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h> Thomas reported U-Boot failed to build host tools if libfdt-devel package is installed because tools include libfdt headers from /usr/include/ instead of using internal ones. This commit moves the header code: include/libfdt.h -> include/linux/libfdt.h include/libfdt_env.h -> include/linux/libfdt_env.h and replaces include directives: #include <libfdt.h> -> #include <linux/libfdt.h> #include <libfdt_env.h> -> #include <linux/libfdt_env.h> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
474a6f5a |
|
04-Dec-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: add comments to memory functions Add comments describing memory functions. Fix the formatting of a function declaration. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f5a2a938 |
|
06-Nov-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: consistently use efi_uintn_t in boot services Consistenly use efi_uintn_t wherever the UEFI spec uses UINTN in boot services interfaces. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
946160f3 |
|
13-Sep-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: make pool allocations cacheline aligned This avoids printf() spam about file reads (such as loading an image) into unaligned buffers (and the associated memcpy()). And generally seems like a good idea. Signed-off-by: Rob Clark <robdclark@gmail.com> [agraf: use __aligned] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
a1b24823 |
|
26-Jul-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: fix bug in efi_get_memory_map When booting shim -> fallback -> shim -> grub -> linux the memory map is a bit larger than the size linux passes in on the first call. But in the EFI_BUFFER_TOO_SMALL case we were not passing back the updated size to linux so it would loop forever. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c6e3c3e6 |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: return MapKey efi_get_memory_map should set a defined value for map_key. We later can introduce the test against this value in efi_exit_boot_services as required by the UEFI standard. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
0ecba5db |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: do parameter checks first The parameter checks should be done first. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
71275a3e |
|
14-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: avoid NULL dereference in efi_free_pool If efi_free_pool is called with argument NULL an illegal memory access occurs. So let's check the parameter on entry. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42633745 |
|
06-Mar-2017 |
York Sun <york.sun@nxp.com> |
efi: Add a hook to allow adding memory mapping Instead of adding all memory banks, add a hook so individual SoC/board can has its own implementation. Signed-off-by: York Sun <york.sun@nxp.com> CC: Alexander Graf <agraf@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
511d0b97 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Do not leak memory when unlinking a mapping As soon as a mapping is unlinked from the list, there are no further references to it, so it should be freed. If it not unlinked, update the start address and length. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b6a95172 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Keep memory mapping sorted when splitting an entry The code assumes sorted mappings in descending address order. When splitting a mapping, insert the new part next to the current mapping. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b61d857b |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Readd freed pages to memory pool 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42417bc8 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Track size of pool allocations to allow freeing 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ead1274b |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Move efi_allocate_pool implementation to efi_memory.c 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
bdf5c1b3 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Fix memory map size check to avoid out-of-bounds access The current efi_get_memory_map() function overwrites the map_size property before reading its value. That way the sanity check whether our memory map fits into the given array always succeeds, potentially overwriting arbitrary payload memory. This patch moves the property update write after its sanity check, so that the check actually verifies the correct value. So far this has not triggered any known bugs, but we're better off safe than sorry. If the buffer is to small, the returned memory_map_size indicates the required size to the caller. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
852efbf5 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Update description of internal efi_mem_carve_out In 74c16acce30bb882ad5951829d8dafef8eea564c the return values where changed, but the description was kept. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4c02c11d |
|
05-Sep-2016 |
Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
efi_loader: provide efi_mem_desc version Provide version of struct efi_mem_desc in efi_get_memory_map(). EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines memory descriptor version to 1. Linux kernel also expects descriptor version to be 1 and prints following warning during boot if its not: Unexpected EFI_MEMORY_DESCRIPTOR version 0 Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
#
c933ed94 |
|
16-Jul-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Add debug output for efi_add_memory_map() Tracing the arguments has been helpful for pinpointing overflows. Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
74c16acc |
|
26-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Don't allocate from memory holes When a payload calls our memory allocator with the exact address hint, we happily allocate memory from completely unpopulated regions. Payloads however expect this to only succeed if they would be allocating from free conventional memory. This patch makes the logic behind those checks a bit more obvious and ensures that we always allocate from known good free conventional memory regions if we want to allocate ram. Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
edcef3ba |
|
02-Jun-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Move to normal debug infrastructure 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> |
#
51735ae0 |
|
11-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Add bounce buffer support 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: Alexander Graf <agraf@suse.de> |
#
dede284d |
|
13-Apr-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Handle memory overflows 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> |
#
cee752fa |
|
11-Apr-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
38ce65e1 |
|
30-Mar-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Always allocate the highest available address 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> |
#
5d00995c |
|
03-Mar-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
ecae4bbf |
|
29-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: memory leak efi_add_memory_map_pg Don't leak newlist if we error out. Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
257a498f |
|
29-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of memory in efi_mem_carve_out Handle out of memory situation in efi_mem_carve_out(). Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
48d183f2 |
|
30-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: overflow in efi_allocate_pages On 32bit systems (pages << EFI_PAGE_SHIFT) may lead to an overflow which does not occur in 64bit arithmetics. An overflow of (pages << EFI_PAGE_SHIFT) on 64bit systems should be treated as an error. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ba275630 |
|
29-Jul-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of memory in efi_add_memory_map_pg Handle out of memory situation in efi_add_memory_map_pg(). Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
207b6864 |
|
05-Apr-2023 |
Bin Meng <bmeng@tinylab.org> |
efi: loader: Make efi_mem static efi_mem is only referenced in efi_memory.c Signed-off-by: Bin Meng <bmeng@tinylab.org> |
#
f606fab8 |
|
19-Mar-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: move dp_alloc() to efi_alloc() The incumbent function efi_alloc() is unused. Replace dp_alloc() by a new function efi_alloc() that we can use more widely. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
0763c02e |
|
07-Jan-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix description of memory functions * Add missing function descriptions * Adjust to Sphinx style Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
eff44401 |
|
05-Jan-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: carve out efi_get_memory_map_alloc() Carve out code from efidebug command used to read the memory map. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
1a127962 |
|
29-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: don't use EFI_LOADER_DATA internally EFI_LOADER_DATA/CODE is reserved for EFI applications. Memory allocated by U-Boot for internal usage should be EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE. Reported-by: François-Frédéric Ozog <ff@ozog.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: François-Frédéric Ozog <ff@ozog.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
53def68d |
|
05-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAddress requires page address AllocatePages() can be called with Type=AllocateAddress. Such a call can only succeed if *Memory points to the address of an unallocated page range. A call with *Memory being an address that is not page aligned must not succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES if the requested pages cannot be allocated. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
8da26f51 |
|
25-Apr-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_add_conventional_memory_map() Remove redundant constraint. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ebdea88d |
|
11-Oct-2021 |
Ilias Apalodimas <ilias.apalodimas@linaro.org> |
efi_loader: Fix loaded image alignment We are ignoring the alignment communicated via the PE/COFF header. Starting 5.10 the Linux kernel will loudly complain about it. For more details look at [1] (in linux kernel). So add a function that can allocate aligned EFI memory and use it for our relocated loaded image. [1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Vincent Stehlé <vincent.stehle@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
49d225e7 |
|
17-Aug-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use correct type for AllocatePages, AllocatePool Use enum efi_memory_type and enum_allocate_type in the definitions of the efi_allocate_pages(), efi_allocate_pool(). In the external UEFI API leave the type as int as the UEFI specification explicitely requires that enums use a 32bit type. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il> |
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b05667c |
|
16-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Merge memory map entries We currently do not combine memory entries that are adjacent and have the same attributes. The problem with that is that our memory map can easily grow multiple hundreds of entries in a simple UEFI Shell environment. So let's make sure we always combine all entries to make the memory map as small as possible. That way every other piece of code that loops through it should also gain some nice speed ups. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
14deb5e6 |
|
30-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "Revert "efi_loader: efi_allocate_pages is too restrictive"" This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710. Now that the underlying issue is fixed, we can revert the revert and hence restore the original EFI code. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <masahiroy@kernel.org> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
9b89183b |
|
14-Jul-2018 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
efi: Fix truncation of constant value Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"), sparse constantly complains about truncated constant value in efi.h: include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0) This can get quite noisy, preventing real issues to be noticed: $ make defconfig *** Default configuration is based on 'sandbox_defconfig' $ make C=2 -j12 2>&1 | grep truncates | wc -l 441 After the patch is applied: $ make C=2 -j12 2>&1 | grep truncates | wc -l 0 $ sparse --version v0.5.2 Following the suggestion of Heinrich Schuchardt, instead of only fixing the root-cause, I replaced the whole enum of _SHIFT values by ULL defines. This matches both the UEFI 2.7 spec and the Linux kernel implementation. Some ELF size comparison before and after the patch (gcc 7.3.0): efi-x86_payload64_defconfig: text data bss dec hex filename 407174 29432 278676 715282 aea12 u-boot.old 407152 29464 278676 715292 aea1c u-boot.new -22 +32 0 +10 efi-x86_payload32_defconfig: text data bss dec hex filename 447075 30308 280076 757459 b8ed3 u-boot.old 447053 30340 280076 757469 b8edd u-boot.new -22 +32 0 +10 Fixes: 867a6ac86dd8 ("efi: Add start-up library code") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
fa995d0d |
|
06-Aug-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid NULL dereference in efi_get_memory_map() We should only dereference parameter memory_map_size after checking that it is valid. Fixes: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ccfc78b8 |
|
02-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "efi_loader: efi_allocate_pages is too restrictive" This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for example when running test/py. Reverting this change isn't optimal, but at least restores TX1 to a working state. In the future, we should: a) Fix whatever problem causes the crash with this patch applied. This needs further discussion, so isn't something we can immediately do. b) Undo the revert; re-apply the original patch to efi_allocate_pages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1fcb7ea2 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check map_key in ExitBootServices The UEFI spec requires that the memory map key is checked in ExitBootServices(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
8e835554 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters of GetMemoryMap Check the parameters of boottime service GetMemoryMap(). Return EFI_INVALID_PARAMETER where required by the UEFI spec. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4d5e071e |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters in memory allocation If no pointer is provided throw an error. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
282a06cb |
|
18-Jun-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Expose U-Boot addresses in memory map for sandbox We currently expose host addresses in the EFI memory map. That can be bad if we ever want to use sandbox to boot strap a real kernel, because then the kernel would fetch its memory table from our host virtual address map. But to make that use case work, we would need to have full control over the address space the EFI application sees. So let's expose only U-Boot addresses to the guest until we get to the point of allocation. EFI's allocation functions are fun - they can take U-Boot addresses as input values for hints and return host addresses as allocation results through the same uint64_t * parameter. So we need to be extra careful on what to pass in when. With this patch I am successfully able to run the efi selftest suite as well as grub.efi on aarch64. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
69259b83 |
|
18-Jun-2018 |
Simon Glass <sjg@chromium.org> |
efi: sandbox: Adjust memory usage for sandbox With sandbox the U-Boot code is not mapped into the sandbox memory range so does not need to be excluded when allocating EFI memory. Update the EFI memory init code to take account of that. Signed-off-by: Simon Glass <sjg@chromium.org> [agraf: Remove map_sysmem() call and header reference] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
aa909462 |
|
18-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_allocate_pages is too restrictive When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory. There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: use -1ULL instead] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
32826140 |
|
27-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_mem_carve_out should return s64 efi_mem_carve_out() is used to remove memory pages from a mapping. As the number of pages to be removed is a 64bit type the return type should be 64bit too. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
e09159c8 |
|
26-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid anonymous constants for AllocatePages Do not use anonymous constants when calling efi_allocage_pages. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1f0532ca |
|
27-Apr-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove unnecessary include asm/global_data.h is already included via common.h. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f739fcd8 |
|
07-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert a few files that were missed before As part of the main conversion a few files were missed. These files had additional whitespace after the '*' and before the SPDX tag and my previous regex was too strict. This time I did a grep for all SPDX tags and then filtered out anything that matched the correct styles. Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style") Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bdecaebd |
|
08-Mar-2018 |
Simon Glass <sjg@chromium.org> |
efi: Correct header order in efi_memory The headers are not in the correct order. Fix this. Also drop libfdt_env.h since it is not needed. Signed-off-by: Simon Glass <sjg@chromium.org> Rebased Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7c92fd69 |
|
30-Jan-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use constants in efi_allocate_pages() Using the existing predefined constants is less error prone and makes the code easier to read. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b08c8c48 |
|
04-Mar-2018 |
Masahiro Yamada <masahiroy@kernel.org> |
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h> Thomas reported U-Boot failed to build host tools if libfdt-devel package is installed because tools include libfdt headers from /usr/include/ instead of using internal ones. This commit moves the header code: include/libfdt.h -> include/linux/libfdt.h include/libfdt_env.h -> include/linux/libfdt_env.h and replaces include directives: #include <libfdt.h> -> #include <linux/libfdt.h> #include <libfdt_env.h> -> #include <linux/libfdt_env.h> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
474a6f5a |
|
04-Dec-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: add comments to memory functions Add comments describing memory functions. Fix the formatting of a function declaration. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f5a2a938 |
|
06-Nov-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: consistently use efi_uintn_t in boot services Consistenly use efi_uintn_t wherever the UEFI spec uses UINTN in boot services interfaces. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
946160f3 |
|
13-Sep-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: make pool allocations cacheline aligned This avoids printf() spam about file reads (such as loading an image) into unaligned buffers (and the associated memcpy()). And generally seems like a good idea. Signed-off-by: Rob Clark <robdclark@gmail.com> [agraf: use __aligned] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
a1b24823 |
|
26-Jul-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: fix bug in efi_get_memory_map When booting shim -> fallback -> shim -> grub -> linux the memory map is a bit larger than the size linux passes in on the first call. But in the EFI_BUFFER_TOO_SMALL case we were not passing back the updated size to linux so it would loop forever. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c6e3c3e6 |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: return MapKey efi_get_memory_map should set a defined value for map_key. We later can introduce the test against this value in efi_exit_boot_services as required by the UEFI standard. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
0ecba5db |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: do parameter checks first The parameter checks should be done first. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
71275a3e |
|
14-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: avoid NULL dereference in efi_free_pool If efi_free_pool is called with argument NULL an illegal memory access occurs. So let's check the parameter on entry. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42633745 |
|
06-Mar-2017 |
York Sun <york.sun@nxp.com> |
efi: Add a hook to allow adding memory mapping Instead of adding all memory banks, add a hook so individual SoC/board can has its own implementation. Signed-off-by: York Sun <york.sun@nxp.com> CC: Alexander Graf <agraf@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
511d0b97 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Do not leak memory when unlinking a mapping As soon as a mapping is unlinked from the list, there are no further references to it, so it should be freed. If it not unlinked, update the start address and length. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b6a95172 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Keep memory mapping sorted when splitting an entry The code assumes sorted mappings in descending address order. When splitting a mapping, insert the new part next to the current mapping. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b61d857b |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Readd freed pages to memory pool 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42417bc8 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Track size of pool allocations to allow freeing 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ead1274b |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Move efi_allocate_pool implementation to efi_memory.c 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
bdf5c1b3 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Fix memory map size check to avoid out-of-bounds access The current efi_get_memory_map() function overwrites the map_size property before reading its value. That way the sanity check whether our memory map fits into the given array always succeeds, potentially overwriting arbitrary payload memory. This patch moves the property update write after its sanity check, so that the check actually verifies the correct value. So far this has not triggered any known bugs, but we're better off safe than sorry. If the buffer is to small, the returned memory_map_size indicates the required size to the caller. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
852efbf5 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Update description of internal efi_mem_carve_out In 74c16acce30bb882ad5951829d8dafef8eea564c the return values where changed, but the description was kept. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4c02c11d |
|
05-Sep-2016 |
Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
efi_loader: provide efi_mem_desc version Provide version of struct efi_mem_desc in efi_get_memory_map(). EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines memory descriptor version to 1. Linux kernel also expects descriptor version to be 1 and prints following warning during boot if its not: Unexpected EFI_MEMORY_DESCRIPTOR version 0 Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
#
c933ed94 |
|
16-Jul-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Add debug output for efi_add_memory_map() Tracing the arguments has been helpful for pinpointing overflows. Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
74c16acc |
|
26-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Don't allocate from memory holes When a payload calls our memory allocator with the exact address hint, we happily allocate memory from completely unpopulated regions. Payloads however expect this to only succeed if they would be allocating from free conventional memory. This patch makes the logic behind those checks a bit more obvious and ensures that we always allocate from known good free conventional memory regions if we want to allocate ram. Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
edcef3ba |
|
02-Jun-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Move to normal debug infrastructure 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> |
#
51735ae0 |
|
11-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Add bounce buffer support 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: Alexander Graf <agraf@suse.de> |
#
dede284d |
|
13-Apr-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Handle memory overflows 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> |
#
cee752fa |
|
11-Apr-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
38ce65e1 |
|
30-Mar-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Always allocate the highest available address 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> |
#
5d00995c |
|
03-Mar-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
207b6864 |
|
05-Apr-2023 |
Bin Meng <bmeng@tinylab.org> |
efi: loader: Make efi_mem static efi_mem is only referenced in efi_memory.c Signed-off-by: Bin Meng <bmeng@tinylab.org> |
#
f606fab8 |
|
19-Mar-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: move dp_alloc() to efi_alloc() The incumbent function efi_alloc() is unused. Replace dp_alloc() by a new function efi_alloc() that we can use more widely. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
0763c02e |
|
07-Jan-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix description of memory functions * Add missing function descriptions * Adjust to Sphinx style Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
eff44401 |
|
05-Jan-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: carve out efi_get_memory_map_alloc() Carve out code from efidebug command used to read the memory map. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
1a127962 |
|
29-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: don't use EFI_LOADER_DATA internally EFI_LOADER_DATA/CODE is reserved for EFI applications. Memory allocated by U-Boot for internal usage should be EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE. Reported-by: François-Frédéric Ozog <ff@ozog.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: François-Frédéric Ozog <ff@ozog.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
53def68d |
|
05-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAddress requires page address AllocatePages() can be called with Type=AllocateAddress. Such a call can only succeed if *Memory points to the address of an unallocated page range. A call with *Memory being an address that is not page aligned must not succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES if the requested pages cannot be allocated. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
8da26f51 |
|
25-Apr-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_add_conventional_memory_map() Remove redundant constraint. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ebdea88d |
|
11-Oct-2021 |
Ilias Apalodimas <ilias.apalodimas@linaro.org> |
efi_loader: Fix loaded image alignment We are ignoring the alignment communicated via the PE/COFF header. Starting 5.10 the Linux kernel will loudly complain about it. For more details look at [1] (in linux kernel). So add a function that can allocate aligned EFI memory and use it for our relocated loaded image. [1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Vincent Stehlé <vincent.stehle@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
49d225e7 |
|
17-Aug-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use correct type for AllocatePages, AllocatePool Use enum efi_memory_type and enum_allocate_type in the definitions of the efi_allocate_pages(), efi_allocate_pool(). In the external UEFI API leave the type as int as the UEFI specification explicitely requires that enums use a 32bit type. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il> |
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b05667c |
|
16-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Merge memory map entries We currently do not combine memory entries that are adjacent and have the same attributes. The problem with that is that our memory map can easily grow multiple hundreds of entries in a simple UEFI Shell environment. So let's make sure we always combine all entries to make the memory map as small as possible. That way every other piece of code that loops through it should also gain some nice speed ups. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
14deb5e6 |
|
30-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "Revert "efi_loader: efi_allocate_pages is too restrictive"" This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710. Now that the underlying issue is fixed, we can revert the revert and hence restore the original EFI code. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
9b89183b |
|
14-Jul-2018 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
efi: Fix truncation of constant value Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"), sparse constantly complains about truncated constant value in efi.h: include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0) This can get quite noisy, preventing real issues to be noticed: $ make defconfig *** Default configuration is based on 'sandbox_defconfig' $ make C=2 -j12 2>&1 | grep truncates | wc -l 441 After the patch is applied: $ make C=2 -j12 2>&1 | grep truncates | wc -l 0 $ sparse --version v0.5.2 Following the suggestion of Heinrich Schuchardt, instead of only fixing the root-cause, I replaced the whole enum of _SHIFT values by ULL defines. This matches both the UEFI 2.7 spec and the Linux kernel implementation. Some ELF size comparison before and after the patch (gcc 7.3.0): efi-x86_payload64_defconfig: text data bss dec hex filename 407174 29432 278676 715282 aea12 u-boot.old 407152 29464 278676 715292 aea1c u-boot.new -22 +32 0 +10 efi-x86_payload32_defconfig: text data bss dec hex filename 447075 30308 280076 757459 b8ed3 u-boot.old 447053 30340 280076 757469 b8edd u-boot.new -22 +32 0 +10 Fixes: 867a6ac86dd8 ("efi: Add start-up library code") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
fa995d0d |
|
06-Aug-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid NULL dereference in efi_get_memory_map() We should only dereference parameter memory_map_size after checking that it is valid. Fixes: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ccfc78b8 |
|
02-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "efi_loader: efi_allocate_pages is too restrictive" This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for example when running test/py. Reverting this change isn't optimal, but at least restores TX1 to a working state. In the future, we should: a) Fix whatever problem causes the crash with this patch applied. This needs further discussion, so isn't something we can immediately do. b) Undo the revert; re-apply the original patch to efi_allocate_pages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1fcb7ea2 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check map_key in ExitBootServices The UEFI spec requires that the memory map key is checked in ExitBootServices(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
8e835554 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters of GetMemoryMap Check the parameters of boottime service GetMemoryMap(). Return EFI_INVALID_PARAMETER where required by the UEFI spec. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4d5e071e |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters in memory allocation If no pointer is provided throw an error. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
282a06cb |
|
18-Jun-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Expose U-Boot addresses in memory map for sandbox We currently expose host addresses in the EFI memory map. That can be bad if we ever want to use sandbox to boot strap a real kernel, because then the kernel would fetch its memory table from our host virtual address map. But to make that use case work, we would need to have full control over the address space the EFI application sees. So let's expose only U-Boot addresses to the guest until we get to the point of allocation. EFI's allocation functions are fun - they can take U-Boot addresses as input values for hints and return host addresses as allocation results through the same uint64_t * parameter. So we need to be extra careful on what to pass in when. With this patch I am successfully able to run the efi selftest suite as well as grub.efi on aarch64. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
69259b83 |
|
18-Jun-2018 |
Simon Glass <sjg@chromium.org> |
efi: sandbox: Adjust memory usage for sandbox With sandbox the U-Boot code is not mapped into the sandbox memory range so does not need to be excluded when allocating EFI memory. Update the EFI memory init code to take account of that. Signed-off-by: Simon Glass <sjg@chromium.org> [agraf: Remove map_sysmem() call and header reference] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
aa909462 |
|
18-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_allocate_pages is too restrictive When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory. There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: use -1ULL instead] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
32826140 |
|
27-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_mem_carve_out should return s64 efi_mem_carve_out() is used to remove memory pages from a mapping. As the number of pages to be removed is a 64bit type the return type should be 64bit too. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
e09159c8 |
|
26-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid anonymous constants for AllocatePages Do not use anonymous constants when calling efi_allocage_pages. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1f0532ca |
|
27-Apr-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove unnecessary include asm/global_data.h is already included via common.h. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f739fcd8 |
|
07-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert a few files that were missed before As part of the main conversion a few files were missed. These files had additional whitespace after the '*' and before the SPDX tag and my previous regex was too strict. This time I did a grep for all SPDX tags and then filtered out anything that matched the correct styles. Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style") Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bdecaebd |
|
08-Mar-2018 |
Simon Glass <sjg@chromium.org> |
efi: Correct header order in efi_memory The headers are not in the correct order. Fix this. Also drop libfdt_env.h since it is not needed. Signed-off-by: Simon Glass <sjg@chromium.org> Rebased Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7c92fd69 |
|
30-Jan-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use constants in efi_allocate_pages() Using the existing predefined constants is less error prone and makes the code easier to read. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b08c8c48 |
|
04-Mar-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h> Thomas reported U-Boot failed to build host tools if libfdt-devel package is installed because tools include libfdt headers from /usr/include/ instead of using internal ones. This commit moves the header code: include/libfdt.h -> include/linux/libfdt.h include/libfdt_env.h -> include/linux/libfdt_env.h and replaces include directives: #include <libfdt.h> -> #include <linux/libfdt.h> #include <libfdt_env.h> -> #include <linux/libfdt_env.h> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
474a6f5a |
|
04-Dec-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: add comments to memory functions Add comments describing memory functions. Fix the formatting of a function declaration. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f5a2a938 |
|
06-Nov-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: consistently use efi_uintn_t in boot services Consistenly use efi_uintn_t wherever the UEFI spec uses UINTN in boot services interfaces. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
946160f3 |
|
13-Sep-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: make pool allocations cacheline aligned This avoids printf() spam about file reads (such as loading an image) into unaligned buffers (and the associated memcpy()). And generally seems like a good idea. Signed-off-by: Rob Clark <robdclark@gmail.com> [agraf: use __aligned] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
a1b24823 |
|
26-Jul-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: fix bug in efi_get_memory_map When booting shim -> fallback -> shim -> grub -> linux the memory map is a bit larger than the size linux passes in on the first call. But in the EFI_BUFFER_TOO_SMALL case we were not passing back the updated size to linux so it would loop forever. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c6e3c3e6 |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: return MapKey efi_get_memory_map should set a defined value for map_key. We later can introduce the test against this value in efi_exit_boot_services as required by the UEFI standard. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
0ecba5db |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: do parameter checks first The parameter checks should be done first. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
71275a3e |
|
14-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: avoid NULL dereference in efi_free_pool If efi_free_pool is called with argument NULL an illegal memory access occurs. So let's check the parameter on entry. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42633745 |
|
06-Mar-2017 |
York Sun <york.sun@nxp.com> |
efi: Add a hook to allow adding memory mapping Instead of adding all memory banks, add a hook so individual SoC/board can has its own implementation. Signed-off-by: York Sun <york.sun@nxp.com> CC: Alexander Graf <agraf@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
511d0b97 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Do not leak memory when unlinking a mapping As soon as a mapping is unlinked from the list, there are no further references to it, so it should be freed. If it not unlinked, update the start address and length. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b6a95172 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Keep memory mapping sorted when splitting an entry The code assumes sorted mappings in descending address order. When splitting a mapping, insert the new part next to the current mapping. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b61d857b |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Readd freed pages to memory pool 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42417bc8 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Track size of pool allocations to allow freeing 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ead1274b |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Move efi_allocate_pool implementation to efi_memory.c 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
bdf5c1b3 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Fix memory map size check to avoid out-of-bounds access The current efi_get_memory_map() function overwrites the map_size property before reading its value. That way the sanity check whether our memory map fits into the given array always succeeds, potentially overwriting arbitrary payload memory. This patch moves the property update write after its sanity check, so that the check actually verifies the correct value. So far this has not triggered any known bugs, but we're better off safe than sorry. If the buffer is to small, the returned memory_map_size indicates the required size to the caller. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
852efbf5 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Update description of internal efi_mem_carve_out In 74c16acce30bb882ad5951829d8dafef8eea564c the return values where changed, but the description was kept. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4c02c11d |
|
05-Sep-2016 |
Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
efi_loader: provide efi_mem_desc version Provide version of struct efi_mem_desc in efi_get_memory_map(). EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines memory descriptor version to 1. Linux kernel also expects descriptor version to be 1 and prints following warning during boot if its not: Unexpected EFI_MEMORY_DESCRIPTOR version 0 Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
#
c933ed94 |
|
16-Jul-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Add debug output for efi_add_memory_map() Tracing the arguments has been helpful for pinpointing overflows. Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
74c16acc |
|
26-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Don't allocate from memory holes When a payload calls our memory allocator with the exact address hint, we happily allocate memory from completely unpopulated regions. Payloads however expect this to only succeed if they would be allocating from free conventional memory. This patch makes the logic behind those checks a bit more obvious and ensures that we always allocate from known good free conventional memory regions if we want to allocate ram. Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
edcef3ba |
|
02-Jun-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Move to normal debug infrastructure 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> |
#
51735ae0 |
|
11-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Add bounce buffer support 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: Alexander Graf <agraf@suse.de> |
#
dede284d |
|
13-Apr-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Handle memory overflows 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> |
#
cee752fa |
|
11-Apr-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
38ce65e1 |
|
30-Mar-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Always allocate the highest available address 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> |
#
5d00995c |
|
03-Mar-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
0763c02e |
|
07-Jan-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix description of memory functions * Add missing function descriptions * Adjust to Sphinx style Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
eff44401 |
|
05-Jan-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: carve out efi_get_memory_map_alloc() Carve out code from efidebug command used to read the memory map. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
1a127962 |
|
29-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: don't use EFI_LOADER_DATA internally EFI_LOADER_DATA/CODE is reserved for EFI applications. Memory allocated by U-Boot for internal usage should be EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE. Reported-by: François-Frédéric Ozog <ff@ozog.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: François-Frédéric Ozog <ff@ozog.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
53def68d |
|
05-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAddress requires page address AllocatePages() can be called with Type=AllocateAddress. Such a call can only succeed if *Memory points to the address of an unallocated page range. A call with *Memory being an address that is not page aligned must not succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES if the requested pages cannot be allocated. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
8da26f51 |
|
25-Apr-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_add_conventional_memory_map() Remove redundant constraint. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ebdea88d |
|
11-Oct-2021 |
Ilias Apalodimas <ilias.apalodimas@linaro.org> |
efi_loader: Fix loaded image alignment We are ignoring the alignment communicated via the PE/COFF header. Starting 5.10 the Linux kernel will loudly complain about it. For more details look at [1] (in linux kernel). So add a function that can allocate aligned EFI memory and use it for our relocated loaded image. [1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Vincent Stehlé <vincent.stehle@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
49d225e7 |
|
17-Aug-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use correct type for AllocatePages, AllocatePool Use enum efi_memory_type and enum_allocate_type in the definitions of the efi_allocate_pages(), efi_allocate_pool(). In the external UEFI API leave the type as int as the UEFI specification explicitely requires that enums use a 32bit type. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il> |
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b05667c |
|
16-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Merge memory map entries We currently do not combine memory entries that are adjacent and have the same attributes. The problem with that is that our memory map can easily grow multiple hundreds of entries in a simple UEFI Shell environment. So let's make sure we always combine all entries to make the memory map as small as possible. That way every other piece of code that loops through it should also gain some nice speed ups. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
14deb5e6 |
|
30-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "Revert "efi_loader: efi_allocate_pages is too restrictive"" This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710. Now that the underlying issue is fixed, we can revert the revert and hence restore the original EFI code. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
9b89183b |
|
14-Jul-2018 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
efi: Fix truncation of constant value Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"), sparse constantly complains about truncated constant value in efi.h: include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0) This can get quite noisy, preventing real issues to be noticed: $ make defconfig *** Default configuration is based on 'sandbox_defconfig' $ make C=2 -j12 2>&1 | grep truncates | wc -l 441 After the patch is applied: $ make C=2 -j12 2>&1 | grep truncates | wc -l 0 $ sparse --version v0.5.2 Following the suggestion of Heinrich Schuchardt, instead of only fixing the root-cause, I replaced the whole enum of _SHIFT values by ULL defines. This matches both the UEFI 2.7 spec and the Linux kernel implementation. Some ELF size comparison before and after the patch (gcc 7.3.0): efi-x86_payload64_defconfig: text data bss dec hex filename 407174 29432 278676 715282 aea12 u-boot.old 407152 29464 278676 715292 aea1c u-boot.new -22 +32 0 +10 efi-x86_payload32_defconfig: text data bss dec hex filename 447075 30308 280076 757459 b8ed3 u-boot.old 447053 30340 280076 757469 b8edd u-boot.new -22 +32 0 +10 Fixes: 867a6ac86dd8 ("efi: Add start-up library code") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
fa995d0d |
|
06-Aug-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid NULL dereference in efi_get_memory_map() We should only dereference parameter memory_map_size after checking that it is valid. Fixes: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ccfc78b8 |
|
02-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "efi_loader: efi_allocate_pages is too restrictive" This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for example when running test/py. Reverting this change isn't optimal, but at least restores TX1 to a working state. In the future, we should: a) Fix whatever problem causes the crash with this patch applied. This needs further discussion, so isn't something we can immediately do. b) Undo the revert; re-apply the original patch to efi_allocate_pages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1fcb7ea2 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check map_key in ExitBootServices The UEFI spec requires that the memory map key is checked in ExitBootServices(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
8e835554 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters of GetMemoryMap Check the parameters of boottime service GetMemoryMap(). Return EFI_INVALID_PARAMETER where required by the UEFI spec. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4d5e071e |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters in memory allocation If no pointer is provided throw an error. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
282a06cb |
|
18-Jun-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Expose U-Boot addresses in memory map for sandbox We currently expose host addresses in the EFI memory map. That can be bad if we ever want to use sandbox to boot strap a real kernel, because then the kernel would fetch its memory table from our host virtual address map. But to make that use case work, we would need to have full control over the address space the EFI application sees. So let's expose only U-Boot addresses to the guest until we get to the point of allocation. EFI's allocation functions are fun - they can take U-Boot addresses as input values for hints and return host addresses as allocation results through the same uint64_t * parameter. So we need to be extra careful on what to pass in when. With this patch I am successfully able to run the efi selftest suite as well as grub.efi on aarch64. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
69259b83 |
|
18-Jun-2018 |
Simon Glass <sjg@chromium.org> |
efi: sandbox: Adjust memory usage for sandbox With sandbox the U-Boot code is not mapped into the sandbox memory range so does not need to be excluded when allocating EFI memory. Update the EFI memory init code to take account of that. Signed-off-by: Simon Glass <sjg@chromium.org> [agraf: Remove map_sysmem() call and header reference] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
aa909462 |
|
18-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_allocate_pages is too restrictive When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory. There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: use -1ULL instead] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
32826140 |
|
27-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_mem_carve_out should return s64 efi_mem_carve_out() is used to remove memory pages from a mapping. As the number of pages to be removed is a 64bit type the return type should be 64bit too. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
e09159c8 |
|
26-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid anonymous constants for AllocatePages Do not use anonymous constants when calling efi_allocage_pages. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1f0532ca |
|
27-Apr-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove unnecessary include asm/global_data.h is already included via common.h. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f739fcd8 |
|
07-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert a few files that were missed before As part of the main conversion a few files were missed. These files had additional whitespace after the '*' and before the SPDX tag and my previous regex was too strict. This time I did a grep for all SPDX tags and then filtered out anything that matched the correct styles. Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style") Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bdecaebd |
|
08-Mar-2018 |
Simon Glass <sjg@chromium.org> |
efi: Correct header order in efi_memory The headers are not in the correct order. Fix this. Also drop libfdt_env.h since it is not needed. Signed-off-by: Simon Glass <sjg@chromium.org> Rebased Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7c92fd69 |
|
30-Jan-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use constants in efi_allocate_pages() Using the existing predefined constants is less error prone and makes the code easier to read. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b08c8c48 |
|
04-Mar-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h> Thomas reported U-Boot failed to build host tools if libfdt-devel package is installed because tools include libfdt headers from /usr/include/ instead of using internal ones. This commit moves the header code: include/libfdt.h -> include/linux/libfdt.h include/libfdt_env.h -> include/linux/libfdt_env.h and replaces include directives: #include <libfdt.h> -> #include <linux/libfdt.h> #include <libfdt_env.h> -> #include <linux/libfdt_env.h> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
474a6f5a |
|
04-Dec-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: add comments to memory functions Add comments describing memory functions. Fix the formatting of a function declaration. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f5a2a938 |
|
06-Nov-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: consistently use efi_uintn_t in boot services Consistenly use efi_uintn_t wherever the UEFI spec uses UINTN in boot services interfaces. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
946160f3 |
|
13-Sep-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: make pool allocations cacheline aligned This avoids printf() spam about file reads (such as loading an image) into unaligned buffers (and the associated memcpy()). And generally seems like a good idea. Signed-off-by: Rob Clark <robdclark@gmail.com> [agraf: use __aligned] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
a1b24823 |
|
26-Jul-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: fix bug in efi_get_memory_map When booting shim -> fallback -> shim -> grub -> linux the memory map is a bit larger than the size linux passes in on the first call. But in the EFI_BUFFER_TOO_SMALL case we were not passing back the updated size to linux so it would loop forever. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c6e3c3e6 |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: return MapKey efi_get_memory_map should set a defined value for map_key. We later can introduce the test against this value in efi_exit_boot_services as required by the UEFI standard. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
0ecba5db |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: do parameter checks first The parameter checks should be done first. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
71275a3e |
|
14-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: avoid NULL dereference in efi_free_pool If efi_free_pool is called with argument NULL an illegal memory access occurs. So let's check the parameter on entry. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42633745 |
|
06-Mar-2017 |
York Sun <york.sun@nxp.com> |
efi: Add a hook to allow adding memory mapping Instead of adding all memory banks, add a hook so individual SoC/board can has its own implementation. Signed-off-by: York Sun <york.sun@nxp.com> CC: Alexander Graf <agraf@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
511d0b97 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Do not leak memory when unlinking a mapping As soon as a mapping is unlinked from the list, there are no further references to it, so it should be freed. If it not unlinked, update the start address and length. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b6a95172 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Keep memory mapping sorted when splitting an entry The code assumes sorted mappings in descending address order. When splitting a mapping, insert the new part next to the current mapping. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b61d857b |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Readd freed pages to memory pool 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42417bc8 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Track size of pool allocations to allow freeing 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ead1274b |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Move efi_allocate_pool implementation to efi_memory.c 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
bdf5c1b3 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Fix memory map size check to avoid out-of-bounds access The current efi_get_memory_map() function overwrites the map_size property before reading its value. That way the sanity check whether our memory map fits into the given array always succeeds, potentially overwriting arbitrary payload memory. This patch moves the property update write after its sanity check, so that the check actually verifies the correct value. So far this has not triggered any known bugs, but we're better off safe than sorry. If the buffer is to small, the returned memory_map_size indicates the required size to the caller. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
852efbf5 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Update description of internal efi_mem_carve_out In 74c16acce30bb882ad5951829d8dafef8eea564c the return values where changed, but the description was kept. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4c02c11d |
|
05-Sep-2016 |
Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
efi_loader: provide efi_mem_desc version Provide version of struct efi_mem_desc in efi_get_memory_map(). EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines memory descriptor version to 1. Linux kernel also expects descriptor version to be 1 and prints following warning during boot if its not: Unexpected EFI_MEMORY_DESCRIPTOR version 0 Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
#
c933ed94 |
|
16-Jul-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Add debug output for efi_add_memory_map() Tracing the arguments has been helpful for pinpointing overflows. Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
74c16acc |
|
26-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Don't allocate from memory holes When a payload calls our memory allocator with the exact address hint, we happily allocate memory from completely unpopulated regions. Payloads however expect this to only succeed if they would be allocating from free conventional memory. This patch makes the logic behind those checks a bit more obvious and ensures that we always allocate from known good free conventional memory regions if we want to allocate ram. Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
edcef3ba |
|
02-Jun-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Move to normal debug infrastructure 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> |
#
51735ae0 |
|
11-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Add bounce buffer support 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: Alexander Graf <agraf@suse.de> |
#
dede284d |
|
13-Apr-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Handle memory overflows 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> |
#
cee752fa |
|
11-Apr-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
38ce65e1 |
|
30-Mar-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Always allocate the highest available address 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> |
#
5d00995c |
|
03-Mar-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
eff44401 |
|
05-Jan-2023 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: carve out efi_get_memory_map_alloc() Carve out code from efidebug command used to read the memory map. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
1a127962 |
|
29-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: don't use EFI_LOADER_DATA internally EFI_LOADER_DATA/CODE is reserved for EFI applications. Memory allocated by U-Boot for internal usage should be EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE. Reported-by: François-Frédéric Ozog <ff@ozog.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: François-Frédéric Ozog <ff@ozog.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
53def68d |
|
05-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAddress requires page address AllocatePages() can be called with Type=AllocateAddress. Such a call can only succeed if *Memory points to the address of an unallocated page range. A call with *Memory being an address that is not page aligned must not succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES if the requested pages cannot be allocated. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
8da26f51 |
|
25-Apr-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_add_conventional_memory_map() Remove redundant constraint. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ebdea88d |
|
11-Oct-2021 |
Ilias Apalodimas <ilias.apalodimas@linaro.org> |
efi_loader: Fix loaded image alignment We are ignoring the alignment communicated via the PE/COFF header. Starting 5.10 the Linux kernel will loudly complain about it. For more details look at [1] (in linux kernel). So add a function that can allocate aligned EFI memory and use it for our relocated loaded image. [1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Vincent Stehlé <vincent.stehle@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
49d225e7 |
|
17-Aug-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use correct type for AllocatePages, AllocatePool Use enum efi_memory_type and enum_allocate_type in the definitions of the efi_allocate_pages(), efi_allocate_pool(). In the external UEFI API leave the type as int as the UEFI specification explicitely requires that enums use a 32bit type. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il> |
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b05667c |
|
16-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Merge memory map entries We currently do not combine memory entries that are adjacent and have the same attributes. The problem with that is that our memory map can easily grow multiple hundreds of entries in a simple UEFI Shell environment. So let's make sure we always combine all entries to make the memory map as small as possible. That way every other piece of code that loops through it should also gain some nice speed ups. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
14deb5e6 |
|
30-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "Revert "efi_loader: efi_allocate_pages is too restrictive"" This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710. Now that the underlying issue is fixed, we can revert the revert and hence restore the original EFI code. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
9b89183b |
|
14-Jul-2018 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
efi: Fix truncation of constant value Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"), sparse constantly complains about truncated constant value in efi.h: include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0) This can get quite noisy, preventing real issues to be noticed: $ make defconfig *** Default configuration is based on 'sandbox_defconfig' $ make C=2 -j12 2>&1 | grep truncates | wc -l 441 After the patch is applied: $ make C=2 -j12 2>&1 | grep truncates | wc -l 0 $ sparse --version v0.5.2 Following the suggestion of Heinrich Schuchardt, instead of only fixing the root-cause, I replaced the whole enum of _SHIFT values by ULL defines. This matches both the UEFI 2.7 spec and the Linux kernel implementation. Some ELF size comparison before and after the patch (gcc 7.3.0): efi-x86_payload64_defconfig: text data bss dec hex filename 407174 29432 278676 715282 aea12 u-boot.old 407152 29464 278676 715292 aea1c u-boot.new -22 +32 0 +10 efi-x86_payload32_defconfig: text data bss dec hex filename 447075 30308 280076 757459 b8ed3 u-boot.old 447053 30340 280076 757469 b8edd u-boot.new -22 +32 0 +10 Fixes: 867a6ac86dd8 ("efi: Add start-up library code") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
fa995d0d |
|
06-Aug-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid NULL dereference in efi_get_memory_map() We should only dereference parameter memory_map_size after checking that it is valid. Fixes: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ccfc78b8 |
|
02-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "efi_loader: efi_allocate_pages is too restrictive" This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for example when running test/py. Reverting this change isn't optimal, but at least restores TX1 to a working state. In the future, we should: a) Fix whatever problem causes the crash with this patch applied. This needs further discussion, so isn't something we can immediately do. b) Undo the revert; re-apply the original patch to efi_allocate_pages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1fcb7ea2 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check map_key in ExitBootServices The UEFI spec requires that the memory map key is checked in ExitBootServices(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
8e835554 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters of GetMemoryMap Check the parameters of boottime service GetMemoryMap(). Return EFI_INVALID_PARAMETER where required by the UEFI spec. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4d5e071e |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters in memory allocation If no pointer is provided throw an error. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
282a06cb |
|
18-Jun-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Expose U-Boot addresses in memory map for sandbox We currently expose host addresses in the EFI memory map. That can be bad if we ever want to use sandbox to boot strap a real kernel, because then the kernel would fetch its memory table from our host virtual address map. But to make that use case work, we would need to have full control over the address space the EFI application sees. So let's expose only U-Boot addresses to the guest until we get to the point of allocation. EFI's allocation functions are fun - they can take U-Boot addresses as input values for hints and return host addresses as allocation results through the same uint64_t * parameter. So we need to be extra careful on what to pass in when. With this patch I am successfully able to run the efi selftest suite as well as grub.efi on aarch64. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
69259b83 |
|
18-Jun-2018 |
Simon Glass <sjg@chromium.org> |
efi: sandbox: Adjust memory usage for sandbox With sandbox the U-Boot code is not mapped into the sandbox memory range so does not need to be excluded when allocating EFI memory. Update the EFI memory init code to take account of that. Signed-off-by: Simon Glass <sjg@chromium.org> [agraf: Remove map_sysmem() call and header reference] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
aa909462 |
|
18-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_allocate_pages is too restrictive When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory. There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: use -1ULL instead] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
32826140 |
|
27-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_mem_carve_out should return s64 efi_mem_carve_out() is used to remove memory pages from a mapping. As the number of pages to be removed is a 64bit type the return type should be 64bit too. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
e09159c8 |
|
26-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid anonymous constants for AllocatePages Do not use anonymous constants when calling efi_allocage_pages. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1f0532ca |
|
27-Apr-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove unnecessary include asm/global_data.h is already included via common.h. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f739fcd8 |
|
07-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert a few files that were missed before As part of the main conversion a few files were missed. These files had additional whitespace after the '*' and before the SPDX tag and my previous regex was too strict. This time I did a grep for all SPDX tags and then filtered out anything that matched the correct styles. Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style") Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bdecaebd |
|
08-Mar-2018 |
Simon Glass <sjg@chromium.org> |
efi: Correct header order in efi_memory The headers are not in the correct order. Fix this. Also drop libfdt_env.h since it is not needed. Signed-off-by: Simon Glass <sjg@chromium.org> Rebased Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7c92fd69 |
|
30-Jan-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use constants in efi_allocate_pages() Using the existing predefined constants is less error prone and makes the code easier to read. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b08c8c48 |
|
04-Mar-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h> Thomas reported U-Boot failed to build host tools if libfdt-devel package is installed because tools include libfdt headers from /usr/include/ instead of using internal ones. This commit moves the header code: include/libfdt.h -> include/linux/libfdt.h include/libfdt_env.h -> include/linux/libfdt_env.h and replaces include directives: #include <libfdt.h> -> #include <linux/libfdt.h> #include <libfdt_env.h> -> #include <linux/libfdt_env.h> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
474a6f5a |
|
04-Dec-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: add comments to memory functions Add comments describing memory functions. Fix the formatting of a function declaration. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f5a2a938 |
|
06-Nov-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: consistently use efi_uintn_t in boot services Consistenly use efi_uintn_t wherever the UEFI spec uses UINTN in boot services interfaces. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
946160f3 |
|
13-Sep-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: make pool allocations cacheline aligned This avoids printf() spam about file reads (such as loading an image) into unaligned buffers (and the associated memcpy()). And generally seems like a good idea. Signed-off-by: Rob Clark <robdclark@gmail.com> [agraf: use __aligned] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
a1b24823 |
|
26-Jul-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: fix bug in efi_get_memory_map When booting shim -> fallback -> shim -> grub -> linux the memory map is a bit larger than the size linux passes in on the first call. But in the EFI_BUFFER_TOO_SMALL case we were not passing back the updated size to linux so it would loop forever. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c6e3c3e6 |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: return MapKey efi_get_memory_map should set a defined value for map_key. We later can introduce the test against this value in efi_exit_boot_services as required by the UEFI standard. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
0ecba5db |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: do parameter checks first The parameter checks should be done first. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
71275a3e |
|
14-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: avoid NULL dereference in efi_free_pool If efi_free_pool is called with argument NULL an illegal memory access occurs. So let's check the parameter on entry. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42633745 |
|
06-Mar-2017 |
York Sun <york.sun@nxp.com> |
efi: Add a hook to allow adding memory mapping Instead of adding all memory banks, add a hook so individual SoC/board can has its own implementation. Signed-off-by: York Sun <york.sun@nxp.com> CC: Alexander Graf <agraf@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
511d0b97 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Do not leak memory when unlinking a mapping As soon as a mapping is unlinked from the list, there are no further references to it, so it should be freed. If it not unlinked, update the start address and length. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b6a95172 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Keep memory mapping sorted when splitting an entry The code assumes sorted mappings in descending address order. When splitting a mapping, insert the new part next to the current mapping. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b61d857b |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Readd freed pages to memory pool 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42417bc8 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Track size of pool allocations to allow freeing 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ead1274b |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Move efi_allocate_pool implementation to efi_memory.c 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
bdf5c1b3 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Fix memory map size check to avoid out-of-bounds access The current efi_get_memory_map() function overwrites the map_size property before reading its value. That way the sanity check whether our memory map fits into the given array always succeeds, potentially overwriting arbitrary payload memory. This patch moves the property update write after its sanity check, so that the check actually verifies the correct value. So far this has not triggered any known bugs, but we're better off safe than sorry. If the buffer is to small, the returned memory_map_size indicates the required size to the caller. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
852efbf5 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Update description of internal efi_mem_carve_out In 74c16acce30bb882ad5951829d8dafef8eea564c the return values where changed, but the description was kept. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4c02c11d |
|
05-Sep-2016 |
Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
efi_loader: provide efi_mem_desc version Provide version of struct efi_mem_desc in efi_get_memory_map(). EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines memory descriptor version to 1. Linux kernel also expects descriptor version to be 1 and prints following warning during boot if its not: Unexpected EFI_MEMORY_DESCRIPTOR version 0 Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
#
c933ed94 |
|
16-Jul-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Add debug output for efi_add_memory_map() Tracing the arguments has been helpful for pinpointing overflows. Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
74c16acc |
|
26-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Don't allocate from memory holes When a payload calls our memory allocator with the exact address hint, we happily allocate memory from completely unpopulated regions. Payloads however expect this to only succeed if they would be allocating from free conventional memory. This patch makes the logic behind those checks a bit more obvious and ensures that we always allocate from known good free conventional memory regions if we want to allocate ram. Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
edcef3ba |
|
02-Jun-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Move to normal debug infrastructure 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> |
#
51735ae0 |
|
11-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Add bounce buffer support 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: Alexander Graf <agraf@suse.de> |
#
dede284d |
|
13-Apr-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Handle memory overflows 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> |
#
cee752fa |
|
11-Apr-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
38ce65e1 |
|
30-Mar-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Always allocate the highest available address 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> |
#
5d00995c |
|
03-Mar-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
1a127962 |
|
29-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: don't use EFI_LOADER_DATA internally EFI_LOADER_DATA/CODE is reserved for EFI applications. Memory allocated by U-Boot for internal usage should be EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE. Reported-by: François-Frédéric Ozog <ff@ozog.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: François-Frédéric Ozog <ff@ozog.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
#
53def68d |
|
05-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAddress requires page address AllocatePages() can be called with Type=AllocateAddress. Such a call can only succeed if *Memory points to the address of an unallocated page range. A call with *Memory being an address that is not page aligned must not succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES if the requested pages cannot be allocated. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
8da26f51 |
|
25-Apr-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_add_conventional_memory_map() Remove redundant constraint. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ebdea88d |
|
11-Oct-2021 |
Ilias Apalodimas <ilias.apalodimas@linaro.org> |
efi_loader: Fix loaded image alignment We are ignoring the alignment communicated via the PE/COFF header. Starting 5.10 the Linux kernel will loudly complain about it. For more details look at [1] (in linux kernel). So add a function that can allocate aligned EFI memory and use it for our relocated loaded image. [1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Vincent Stehlé <vincent.stehle@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
49d225e7 |
|
17-Aug-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use correct type for AllocatePages, AllocatePool Use enum efi_memory_type and enum_allocate_type in the definitions of the efi_allocate_pages(), efi_allocate_pool(). In the external UEFI API leave the type as int as the UEFI specification explicitely requires that enums use a 32bit type. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il> |
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b05667c |
|
16-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Merge memory map entries We currently do not combine memory entries that are adjacent and have the same attributes. The problem with that is that our memory map can easily grow multiple hundreds of entries in a simple UEFI Shell environment. So let's make sure we always combine all entries to make the memory map as small as possible. That way every other piece of code that loops through it should also gain some nice speed ups. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
14deb5e6 |
|
30-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "Revert "efi_loader: efi_allocate_pages is too restrictive"" This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710. Now that the underlying issue is fixed, we can revert the revert and hence restore the original EFI code. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
9b89183b |
|
14-Jul-2018 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
efi: Fix truncation of constant value Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"), sparse constantly complains about truncated constant value in efi.h: include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0) This can get quite noisy, preventing real issues to be noticed: $ make defconfig *** Default configuration is based on 'sandbox_defconfig' $ make C=2 -j12 2>&1 | grep truncates | wc -l 441 After the patch is applied: $ make C=2 -j12 2>&1 | grep truncates | wc -l 0 $ sparse --version v0.5.2 Following the suggestion of Heinrich Schuchardt, instead of only fixing the root-cause, I replaced the whole enum of _SHIFT values by ULL defines. This matches both the UEFI 2.7 spec and the Linux kernel implementation. Some ELF size comparison before and after the patch (gcc 7.3.0): efi-x86_payload64_defconfig: text data bss dec hex filename 407174 29432 278676 715282 aea12 u-boot.old 407152 29464 278676 715292 aea1c u-boot.new -22 +32 0 +10 efi-x86_payload32_defconfig: text data bss dec hex filename 447075 30308 280076 757459 b8ed3 u-boot.old 447053 30340 280076 757469 b8edd u-boot.new -22 +32 0 +10 Fixes: 867a6ac86dd8 ("efi: Add start-up library code") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
fa995d0d |
|
06-Aug-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid NULL dereference in efi_get_memory_map() We should only dereference parameter memory_map_size after checking that it is valid. Fixes: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ccfc78b8 |
|
02-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "efi_loader: efi_allocate_pages is too restrictive" This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for example when running test/py. Reverting this change isn't optimal, but at least restores TX1 to a working state. In the future, we should: a) Fix whatever problem causes the crash with this patch applied. This needs further discussion, so isn't something we can immediately do. b) Undo the revert; re-apply the original patch to efi_allocate_pages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1fcb7ea2 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check map_key in ExitBootServices The UEFI spec requires that the memory map key is checked in ExitBootServices(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
8e835554 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters of GetMemoryMap Check the parameters of boottime service GetMemoryMap(). Return EFI_INVALID_PARAMETER where required by the UEFI spec. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4d5e071e |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters in memory allocation If no pointer is provided throw an error. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
282a06cb |
|
18-Jun-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Expose U-Boot addresses in memory map for sandbox We currently expose host addresses in the EFI memory map. That can be bad if we ever want to use sandbox to boot strap a real kernel, because then the kernel would fetch its memory table from our host virtual address map. But to make that use case work, we would need to have full control over the address space the EFI application sees. So let's expose only U-Boot addresses to the guest until we get to the point of allocation. EFI's allocation functions are fun - they can take U-Boot addresses as input values for hints and return host addresses as allocation results through the same uint64_t * parameter. So we need to be extra careful on what to pass in when. With this patch I am successfully able to run the efi selftest suite as well as grub.efi on aarch64. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
69259b83 |
|
18-Jun-2018 |
Simon Glass <sjg@chromium.org> |
efi: sandbox: Adjust memory usage for sandbox With sandbox the U-Boot code is not mapped into the sandbox memory range so does not need to be excluded when allocating EFI memory. Update the EFI memory init code to take account of that. Signed-off-by: Simon Glass <sjg@chromium.org> [agraf: Remove map_sysmem() call and header reference] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
aa909462 |
|
18-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_allocate_pages is too restrictive When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory. There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: use -1ULL instead] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
32826140 |
|
27-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_mem_carve_out should return s64 efi_mem_carve_out() is used to remove memory pages from a mapping. As the number of pages to be removed is a 64bit type the return type should be 64bit too. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
e09159c8 |
|
26-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid anonymous constants for AllocatePages Do not use anonymous constants when calling efi_allocage_pages. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1f0532ca |
|
27-Apr-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove unnecessary include asm/global_data.h is already included via common.h. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f739fcd8 |
|
07-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert a few files that were missed before As part of the main conversion a few files were missed. These files had additional whitespace after the '*' and before the SPDX tag and my previous regex was too strict. This time I did a grep for all SPDX tags and then filtered out anything that matched the correct styles. Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style") Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bdecaebd |
|
08-Mar-2018 |
Simon Glass <sjg@chromium.org> |
efi: Correct header order in efi_memory The headers are not in the correct order. Fix this. Also drop libfdt_env.h since it is not needed. Signed-off-by: Simon Glass <sjg@chromium.org> Rebased Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7c92fd69 |
|
30-Jan-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use constants in efi_allocate_pages() Using the existing predefined constants is less error prone and makes the code easier to read. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b08c8c48 |
|
04-Mar-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h> Thomas reported U-Boot failed to build host tools if libfdt-devel package is installed because tools include libfdt headers from /usr/include/ instead of using internal ones. This commit moves the header code: include/libfdt.h -> include/linux/libfdt.h include/libfdt_env.h -> include/linux/libfdt_env.h and replaces include directives: #include <libfdt.h> -> #include <linux/libfdt.h> #include <libfdt_env.h> -> #include <linux/libfdt_env.h> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
474a6f5a |
|
04-Dec-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: add comments to memory functions Add comments describing memory functions. Fix the formatting of a function declaration. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f5a2a938 |
|
06-Nov-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: consistently use efi_uintn_t in boot services Consistenly use efi_uintn_t wherever the UEFI spec uses UINTN in boot services interfaces. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
946160f3 |
|
13-Sep-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: make pool allocations cacheline aligned This avoids printf() spam about file reads (such as loading an image) into unaligned buffers (and the associated memcpy()). And generally seems like a good idea. Signed-off-by: Rob Clark <robdclark@gmail.com> [agraf: use __aligned] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
a1b24823 |
|
26-Jul-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: fix bug in efi_get_memory_map When booting shim -> fallback -> shim -> grub -> linux the memory map is a bit larger than the size linux passes in on the first call. But in the EFI_BUFFER_TOO_SMALL case we were not passing back the updated size to linux so it would loop forever. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c6e3c3e6 |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: return MapKey efi_get_memory_map should set a defined value for map_key. We later can introduce the test against this value in efi_exit_boot_services as required by the UEFI standard. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
0ecba5db |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: do parameter checks first The parameter checks should be done first. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
71275a3e |
|
14-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: avoid NULL dereference in efi_free_pool If efi_free_pool is called with argument NULL an illegal memory access occurs. So let's check the parameter on entry. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42633745 |
|
06-Mar-2017 |
York Sun <york.sun@nxp.com> |
efi: Add a hook to allow adding memory mapping Instead of adding all memory banks, add a hook so individual SoC/board can has its own implementation. Signed-off-by: York Sun <york.sun@nxp.com> CC: Alexander Graf <agraf@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
511d0b97 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Do not leak memory when unlinking a mapping As soon as a mapping is unlinked from the list, there are no further references to it, so it should be freed. If it not unlinked, update the start address and length. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b6a95172 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Keep memory mapping sorted when splitting an entry The code assumes sorted mappings in descending address order. When splitting a mapping, insert the new part next to the current mapping. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b61d857b |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Readd freed pages to memory pool 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42417bc8 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Track size of pool allocations to allow freeing 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ead1274b |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Move efi_allocate_pool implementation to efi_memory.c 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
bdf5c1b3 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Fix memory map size check to avoid out-of-bounds access The current efi_get_memory_map() function overwrites the map_size property before reading its value. That way the sanity check whether our memory map fits into the given array always succeeds, potentially overwriting arbitrary payload memory. This patch moves the property update write after its sanity check, so that the check actually verifies the correct value. So far this has not triggered any known bugs, but we're better off safe than sorry. If the buffer is to small, the returned memory_map_size indicates the required size to the caller. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
852efbf5 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Update description of internal efi_mem_carve_out In 74c16acce30bb882ad5951829d8dafef8eea564c the return values where changed, but the description was kept. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4c02c11d |
|
05-Sep-2016 |
Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
efi_loader: provide efi_mem_desc version Provide version of struct efi_mem_desc in efi_get_memory_map(). EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines memory descriptor version to 1. Linux kernel also expects descriptor version to be 1 and prints following warning during boot if its not: Unexpected EFI_MEMORY_DESCRIPTOR version 0 Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
#
c933ed94 |
|
16-Jul-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Add debug output for efi_add_memory_map() Tracing the arguments has been helpful for pinpointing overflows. Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
74c16acc |
|
26-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Don't allocate from memory holes When a payload calls our memory allocator with the exact address hint, we happily allocate memory from completely unpopulated regions. Payloads however expect this to only succeed if they would be allocating from free conventional memory. This patch makes the logic behind those checks a bit more obvious and ensures that we always allocate from known good free conventional memory regions if we want to allocate ram. Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
edcef3ba |
|
02-Jun-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Move to normal debug infrastructure 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> |
#
51735ae0 |
|
11-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Add bounce buffer support 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: Alexander Graf <agraf@suse.de> |
#
dede284d |
|
13-Apr-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Handle memory overflows 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> |
#
cee752fa |
|
11-Apr-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
38ce65e1 |
|
30-Mar-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Always allocate the highest available address 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> |
#
5d00995c |
|
03-Mar-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
53def68d |
|
05-Nov-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAddress requires page address AllocatePages() can be called with Type=AllocateAddress. Such a call can only succeed if *Memory points to the address of an unallocated page range. A call with *Memory being an address that is not page aligned must not succeed. The UEFI specification requires returning EFI_OUT_OF_RESOURCES if the requested pages cannot be allocated. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
8da26f51 |
|
25-Apr-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_add_conventional_memory_map() Remove redundant constraint. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ebdea88d |
|
11-Oct-2021 |
Ilias Apalodimas <ilias.apalodimas@linaro.org> |
efi_loader: Fix loaded image alignment We are ignoring the alignment communicated via the PE/COFF header. Starting 5.10 the Linux kernel will loudly complain about it. For more details look at [1] (in linux kernel). So add a function that can allocate aligned EFI memory and use it for our relocated loaded image. [1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Vincent Stehlé <vincent.stehle@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
49d225e7 |
|
17-Aug-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use correct type for AllocatePages, AllocatePool Use enum efi_memory_type and enum_allocate_type in the definitions of the efi_allocate_pages(), efi_allocate_pool(). In the external UEFI API leave the type as int as the UEFI specification explicitely requires that enums use a 32bit type. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il> |
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b05667c |
|
16-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Merge memory map entries We currently do not combine memory entries that are adjacent and have the same attributes. The problem with that is that our memory map can easily grow multiple hundreds of entries in a simple UEFI Shell environment. So let's make sure we always combine all entries to make the memory map as small as possible. That way every other piece of code that loops through it should also gain some nice speed ups. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
14deb5e6 |
|
30-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "Revert "efi_loader: efi_allocate_pages is too restrictive"" This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710. Now that the underlying issue is fixed, we can revert the revert and hence restore the original EFI code. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
9b89183b |
|
14-Jul-2018 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
efi: Fix truncation of constant value Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"), sparse constantly complains about truncated constant value in efi.h: include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0) This can get quite noisy, preventing real issues to be noticed: $ make defconfig *** Default configuration is based on 'sandbox_defconfig' $ make C=2 -j12 2>&1 | grep truncates | wc -l 441 After the patch is applied: $ make C=2 -j12 2>&1 | grep truncates | wc -l 0 $ sparse --version v0.5.2 Following the suggestion of Heinrich Schuchardt, instead of only fixing the root-cause, I replaced the whole enum of _SHIFT values by ULL defines. This matches both the UEFI 2.7 spec and the Linux kernel implementation. Some ELF size comparison before and after the patch (gcc 7.3.0): efi-x86_payload64_defconfig: text data bss dec hex filename 407174 29432 278676 715282 aea12 u-boot.old 407152 29464 278676 715292 aea1c u-boot.new -22 +32 0 +10 efi-x86_payload32_defconfig: text data bss dec hex filename 447075 30308 280076 757459 b8ed3 u-boot.old 447053 30340 280076 757469 b8edd u-boot.new -22 +32 0 +10 Fixes: 867a6ac86dd8 ("efi: Add start-up library code") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
fa995d0d |
|
06-Aug-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid NULL dereference in efi_get_memory_map() We should only dereference parameter memory_map_size after checking that it is valid. Fixes: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ccfc78b8 |
|
02-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "efi_loader: efi_allocate_pages is too restrictive" This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for example when running test/py. Reverting this change isn't optimal, but at least restores TX1 to a working state. In the future, we should: a) Fix whatever problem causes the crash with this patch applied. This needs further discussion, so isn't something we can immediately do. b) Undo the revert; re-apply the original patch to efi_allocate_pages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1fcb7ea2 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check map_key in ExitBootServices The UEFI spec requires that the memory map key is checked in ExitBootServices(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
8e835554 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters of GetMemoryMap Check the parameters of boottime service GetMemoryMap(). Return EFI_INVALID_PARAMETER where required by the UEFI spec. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4d5e071e |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters in memory allocation If no pointer is provided throw an error. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
282a06cb |
|
18-Jun-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Expose U-Boot addresses in memory map for sandbox We currently expose host addresses in the EFI memory map. That can be bad if we ever want to use sandbox to boot strap a real kernel, because then the kernel would fetch its memory table from our host virtual address map. But to make that use case work, we would need to have full control over the address space the EFI application sees. So let's expose only U-Boot addresses to the guest until we get to the point of allocation. EFI's allocation functions are fun - they can take U-Boot addresses as input values for hints and return host addresses as allocation results through the same uint64_t * parameter. So we need to be extra careful on what to pass in when. With this patch I am successfully able to run the efi selftest suite as well as grub.efi on aarch64. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
69259b83 |
|
18-Jun-2018 |
Simon Glass <sjg@chromium.org> |
efi: sandbox: Adjust memory usage for sandbox With sandbox the U-Boot code is not mapped into the sandbox memory range so does not need to be excluded when allocating EFI memory. Update the EFI memory init code to take account of that. Signed-off-by: Simon Glass <sjg@chromium.org> [agraf: Remove map_sysmem() call and header reference] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
aa909462 |
|
18-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_allocate_pages is too restrictive When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory. There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: use -1ULL instead] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
32826140 |
|
27-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_mem_carve_out should return s64 efi_mem_carve_out() is used to remove memory pages from a mapping. As the number of pages to be removed is a 64bit type the return type should be 64bit too. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
e09159c8 |
|
26-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid anonymous constants for AllocatePages Do not use anonymous constants when calling efi_allocage_pages. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1f0532ca |
|
27-Apr-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove unnecessary include asm/global_data.h is already included via common.h. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f739fcd8 |
|
07-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert a few files that were missed before As part of the main conversion a few files were missed. These files had additional whitespace after the '*' and before the SPDX tag and my previous regex was too strict. This time I did a grep for all SPDX tags and then filtered out anything that matched the correct styles. Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style") Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bdecaebd |
|
08-Mar-2018 |
Simon Glass <sjg@chromium.org> |
efi: Correct header order in efi_memory The headers are not in the correct order. Fix this. Also drop libfdt_env.h since it is not needed. Signed-off-by: Simon Glass <sjg@chromium.org> Rebased Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7c92fd69 |
|
30-Jan-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use constants in efi_allocate_pages() Using the existing predefined constants is less error prone and makes the code easier to read. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b08c8c48 |
|
04-Mar-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h> Thomas reported U-Boot failed to build host tools if libfdt-devel package is installed because tools include libfdt headers from /usr/include/ instead of using internal ones. This commit moves the header code: include/libfdt.h -> include/linux/libfdt.h include/libfdt_env.h -> include/linux/libfdt_env.h and replaces include directives: #include <libfdt.h> -> #include <linux/libfdt.h> #include <libfdt_env.h> -> #include <linux/libfdt_env.h> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
474a6f5a |
|
04-Dec-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: add comments to memory functions Add comments describing memory functions. Fix the formatting of a function declaration. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f5a2a938 |
|
06-Nov-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: consistently use efi_uintn_t in boot services Consistenly use efi_uintn_t wherever the UEFI spec uses UINTN in boot services interfaces. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
946160f3 |
|
13-Sep-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: make pool allocations cacheline aligned This avoids printf() spam about file reads (such as loading an image) into unaligned buffers (and the associated memcpy()). And generally seems like a good idea. Signed-off-by: Rob Clark <robdclark@gmail.com> [agraf: use __aligned] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
a1b24823 |
|
26-Jul-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: fix bug in efi_get_memory_map When booting shim -> fallback -> shim -> grub -> linux the memory map is a bit larger than the size linux passes in on the first call. But in the EFI_BUFFER_TOO_SMALL case we were not passing back the updated size to linux so it would loop forever. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c6e3c3e6 |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: return MapKey efi_get_memory_map should set a defined value for map_key. We later can introduce the test against this value in efi_exit_boot_services as required by the UEFI standard. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
0ecba5db |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: do parameter checks first The parameter checks should be done first. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
71275a3e |
|
14-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: avoid NULL dereference in efi_free_pool If efi_free_pool is called with argument NULL an illegal memory access occurs. So let's check the parameter on entry. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42633745 |
|
06-Mar-2017 |
York Sun <york.sun@nxp.com> |
efi: Add a hook to allow adding memory mapping Instead of adding all memory banks, add a hook so individual SoC/board can has its own implementation. Signed-off-by: York Sun <york.sun@nxp.com> CC: Alexander Graf <agraf@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
511d0b97 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Do not leak memory when unlinking a mapping As soon as a mapping is unlinked from the list, there are no further references to it, so it should be freed. If it not unlinked, update the start address and length. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b6a95172 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Keep memory mapping sorted when splitting an entry The code assumes sorted mappings in descending address order. When splitting a mapping, insert the new part next to the current mapping. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b61d857b |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Readd freed pages to memory pool 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42417bc8 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Track size of pool allocations to allow freeing 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ead1274b |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Move efi_allocate_pool implementation to efi_memory.c 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
bdf5c1b3 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Fix memory map size check to avoid out-of-bounds access The current efi_get_memory_map() function overwrites the map_size property before reading its value. That way the sanity check whether our memory map fits into the given array always succeeds, potentially overwriting arbitrary payload memory. This patch moves the property update write after its sanity check, so that the check actually verifies the correct value. So far this has not triggered any known bugs, but we're better off safe than sorry. If the buffer is to small, the returned memory_map_size indicates the required size to the caller. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
852efbf5 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Update description of internal efi_mem_carve_out In 74c16acce30bb882ad5951829d8dafef8eea564c the return values where changed, but the description was kept. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4c02c11d |
|
05-Sep-2016 |
Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
efi_loader: provide efi_mem_desc version Provide version of struct efi_mem_desc in efi_get_memory_map(). EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines memory descriptor version to 1. Linux kernel also expects descriptor version to be 1 and prints following warning during boot if its not: Unexpected EFI_MEMORY_DESCRIPTOR version 0 Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
#
c933ed94 |
|
16-Jul-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Add debug output for efi_add_memory_map() Tracing the arguments has been helpful for pinpointing overflows. Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
74c16acc |
|
26-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Don't allocate from memory holes When a payload calls our memory allocator with the exact address hint, we happily allocate memory from completely unpopulated regions. Payloads however expect this to only succeed if they would be allocating from free conventional memory. This patch makes the logic behind those checks a bit more obvious and ensures that we always allocate from known good free conventional memory regions if we want to allocate ram. Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
edcef3ba |
|
02-Jun-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Move to normal debug infrastructure 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> |
#
51735ae0 |
|
11-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Add bounce buffer support 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: Alexander Graf <agraf@suse.de> |
#
dede284d |
|
13-Apr-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Handle memory overflows 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> |
#
cee752fa |
|
11-Apr-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
38ce65e1 |
|
30-Mar-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Always allocate the highest available address 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> |
#
5d00995c |
|
03-Mar-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
8da26f51 |
|
25-Apr-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_add_conventional_memory_map() Remove redundant constraint. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ebdea88d |
|
11-Oct-2021 |
Ilias Apalodimas <ilias.apalodimas@linaro.org> |
efi_loader: Fix loaded image alignment We are ignoring the alignment communicated via the PE/COFF header. Starting 5.10 the Linux kernel will loudly complain about it. For more details look at [1] (in linux kernel). So add a function that can allocate aligned EFI memory and use it for our relocated loaded image. [1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Vincent Stehlé <vincent.stehle@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
49d225e7 |
|
17-Aug-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use correct type for AllocatePages, AllocatePool Use enum efi_memory_type and enum_allocate_type in the definitions of the efi_allocate_pages(), efi_allocate_pool(). In the external UEFI API leave the type as int as the UEFI specification explicitely requires that enums use a 32bit type. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il> |
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b05667c |
|
16-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Merge memory map entries We currently do not combine memory entries that are adjacent and have the same attributes. The problem with that is that our memory map can easily grow multiple hundreds of entries in a simple UEFI Shell environment. So let's make sure we always combine all entries to make the memory map as small as possible. That way every other piece of code that loops through it should also gain some nice speed ups. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
14deb5e6 |
|
30-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "Revert "efi_loader: efi_allocate_pages is too restrictive"" This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710. Now that the underlying issue is fixed, we can revert the revert and hence restore the original EFI code. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
9b89183b |
|
14-Jul-2018 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
efi: Fix truncation of constant value Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"), sparse constantly complains about truncated constant value in efi.h: include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0) This can get quite noisy, preventing real issues to be noticed: $ make defconfig *** Default configuration is based on 'sandbox_defconfig' $ make C=2 -j12 2>&1 | grep truncates | wc -l 441 After the patch is applied: $ make C=2 -j12 2>&1 | grep truncates | wc -l 0 $ sparse --version v0.5.2 Following the suggestion of Heinrich Schuchardt, instead of only fixing the root-cause, I replaced the whole enum of _SHIFT values by ULL defines. This matches both the UEFI 2.7 spec and the Linux kernel implementation. Some ELF size comparison before and after the patch (gcc 7.3.0): efi-x86_payload64_defconfig: text data bss dec hex filename 407174 29432 278676 715282 aea12 u-boot.old 407152 29464 278676 715292 aea1c u-boot.new -22 +32 0 +10 efi-x86_payload32_defconfig: text data bss dec hex filename 447075 30308 280076 757459 b8ed3 u-boot.old 447053 30340 280076 757469 b8edd u-boot.new -22 +32 0 +10 Fixes: 867a6ac86dd8 ("efi: Add start-up library code") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
fa995d0d |
|
06-Aug-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid NULL dereference in efi_get_memory_map() We should only dereference parameter memory_map_size after checking that it is valid. Fixes: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ccfc78b8 |
|
02-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "efi_loader: efi_allocate_pages is too restrictive" This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for example when running test/py. Reverting this change isn't optimal, but at least restores TX1 to a working state. In the future, we should: a) Fix whatever problem causes the crash with this patch applied. This needs further discussion, so isn't something we can immediately do. b) Undo the revert; re-apply the original patch to efi_allocate_pages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1fcb7ea2 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check map_key in ExitBootServices The UEFI spec requires that the memory map key is checked in ExitBootServices(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
8e835554 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters of GetMemoryMap Check the parameters of boottime service GetMemoryMap(). Return EFI_INVALID_PARAMETER where required by the UEFI spec. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4d5e071e |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters in memory allocation If no pointer is provided throw an error. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
282a06cb |
|
18-Jun-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Expose U-Boot addresses in memory map for sandbox We currently expose host addresses in the EFI memory map. That can be bad if we ever want to use sandbox to boot strap a real kernel, because then the kernel would fetch its memory table from our host virtual address map. But to make that use case work, we would need to have full control over the address space the EFI application sees. So let's expose only U-Boot addresses to the guest until we get to the point of allocation. EFI's allocation functions are fun - they can take U-Boot addresses as input values for hints and return host addresses as allocation results through the same uint64_t * parameter. So we need to be extra careful on what to pass in when. With this patch I am successfully able to run the efi selftest suite as well as grub.efi on aarch64. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
69259b83 |
|
18-Jun-2018 |
Simon Glass <sjg@chromium.org> |
efi: sandbox: Adjust memory usage for sandbox With sandbox the U-Boot code is not mapped into the sandbox memory range so does not need to be excluded when allocating EFI memory. Update the EFI memory init code to take account of that. Signed-off-by: Simon Glass <sjg@chromium.org> [agraf: Remove map_sysmem() call and header reference] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
aa909462 |
|
18-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_allocate_pages is too restrictive When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory. There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: use -1ULL instead] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
32826140 |
|
27-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_mem_carve_out should return s64 efi_mem_carve_out() is used to remove memory pages from a mapping. As the number of pages to be removed is a 64bit type the return type should be 64bit too. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
e09159c8 |
|
26-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid anonymous constants for AllocatePages Do not use anonymous constants when calling efi_allocage_pages. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1f0532ca |
|
27-Apr-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove unnecessary include asm/global_data.h is already included via common.h. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f739fcd8 |
|
07-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert a few files that were missed before As part of the main conversion a few files were missed. These files had additional whitespace after the '*' and before the SPDX tag and my previous regex was too strict. This time I did a grep for all SPDX tags and then filtered out anything that matched the correct styles. Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style") Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bdecaebd |
|
08-Mar-2018 |
Simon Glass <sjg@chromium.org> |
efi: Correct header order in efi_memory The headers are not in the correct order. Fix this. Also drop libfdt_env.h since it is not needed. Signed-off-by: Simon Glass <sjg@chromium.org> Rebased Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7c92fd69 |
|
30-Jan-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use constants in efi_allocate_pages() Using the existing predefined constants is less error prone and makes the code easier to read. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b08c8c48 |
|
04-Mar-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h> Thomas reported U-Boot failed to build host tools if libfdt-devel package is installed because tools include libfdt headers from /usr/include/ instead of using internal ones. This commit moves the header code: include/libfdt.h -> include/linux/libfdt.h include/libfdt_env.h -> include/linux/libfdt_env.h and replaces include directives: #include <libfdt.h> -> #include <linux/libfdt.h> #include <libfdt_env.h> -> #include <linux/libfdt_env.h> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
474a6f5a |
|
04-Dec-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: add comments to memory functions Add comments describing memory functions. Fix the formatting of a function declaration. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f5a2a938 |
|
06-Nov-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: consistently use efi_uintn_t in boot services Consistenly use efi_uintn_t wherever the UEFI spec uses UINTN in boot services interfaces. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
946160f3 |
|
13-Sep-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: make pool allocations cacheline aligned This avoids printf() spam about file reads (such as loading an image) into unaligned buffers (and the associated memcpy()). And generally seems like a good idea. Signed-off-by: Rob Clark <robdclark@gmail.com> [agraf: use __aligned] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
a1b24823 |
|
26-Jul-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: fix bug in efi_get_memory_map When booting shim -> fallback -> shim -> grub -> linux the memory map is a bit larger than the size linux passes in on the first call. But in the EFI_BUFFER_TOO_SMALL case we were not passing back the updated size to linux so it would loop forever. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c6e3c3e6 |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: return MapKey efi_get_memory_map should set a defined value for map_key. We later can introduce the test against this value in efi_exit_boot_services as required by the UEFI standard. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
0ecba5db |
|
21-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: do parameter checks first The parameter checks should be done first. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
71275a3e |
|
14-Jul-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_memory: avoid NULL dereference in efi_free_pool If efi_free_pool is called with argument NULL an illegal memory access occurs. So let's check the parameter on entry. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42633745 |
|
06-Mar-2017 |
York Sun <york.sun@nxp.com> |
efi: Add a hook to allow adding memory mapping Instead of adding all memory banks, add a hook so individual SoC/board can has its own implementation. Signed-off-by: York Sun <york.sun@nxp.com> CC: Alexander Graf <agraf@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
511d0b97 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Do not leak memory when unlinking a mapping As soon as a mapping is unlinked from the list, there are no further references to it, so it should be freed. If it not unlinked, update the start address and length. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b6a95172 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Keep memory mapping sorted when splitting an entry The code assumes sorted mappings in descending address order. When splitting a mapping, insert the new part next to the current mapping. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b61d857b |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Readd freed pages to memory pool 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42417bc8 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Track size of pool allocations to allow freeing 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ead1274b |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Move efi_allocate_pool implementation to efi_memory.c 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
bdf5c1b3 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Fix memory map size check to avoid out-of-bounds access The current efi_get_memory_map() function overwrites the map_size property before reading its value. That way the sanity check whether our memory map fits into the given array always succeeds, potentially overwriting arbitrary payload memory. This patch moves the property update write after its sanity check, so that the check actually verifies the correct value. So far this has not triggered any known bugs, but we're better off safe than sorry. If the buffer is to small, the returned memory_map_size indicates the required size to the caller. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
852efbf5 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Update description of internal efi_mem_carve_out In 74c16acce30bb882ad5951829d8dafef8eea564c the return values where changed, but the description was kept. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4c02c11d |
|
05-Sep-2016 |
Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
efi_loader: provide efi_mem_desc version Provide version of struct efi_mem_desc in efi_get_memory_map(). EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines memory descriptor version to 1. Linux kernel also expects descriptor version to be 1 and prints following warning during boot if its not: Unexpected EFI_MEMORY_DESCRIPTOR version 0 Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
#
c933ed94 |
|
16-Jul-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Add debug output for efi_add_memory_map() Tracing the arguments has been helpful for pinpointing overflows. Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
74c16acc |
|
26-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Don't allocate from memory holes When a payload calls our memory allocator with the exact address hint, we happily allocate memory from completely unpopulated regions. Payloads however expect this to only succeed if they would be allocating from free conventional memory. This patch makes the logic behind those checks a bit more obvious and ensures that we always allocate from known good free conventional memory regions if we want to allocate ram. Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
edcef3ba |
|
02-Jun-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Move to normal debug infrastructure 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> |
#
51735ae0 |
|
11-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Add bounce buffer support 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: Alexander Graf <agraf@suse.de> |
#
dede284d |
|
13-Apr-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Handle memory overflows 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> |
#
cee752fa |
|
11-Apr-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
38ce65e1 |
|
30-Mar-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Always allocate the highest available address 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> |
#
5d00995c |
|
03-Mar-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
185f812c |
|
19-Jan-2022 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
ebdea88d |
|
11-Oct-2021 |
Ilias Apalodimas <ilias.apalodimas@linaro.org> |
efi_loader: Fix loaded image alignment We are ignoring the alignment communicated via the PE/COFF header. Starting 5.10 the Linux kernel will loudly complain about it. For more details look at [1] (in linux kernel). So add a function that can allocate aligned EFI memory and use it for our relocated loaded image. [1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Vincent Stehlé <vincent.stehle@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
49d225e7 |
|
17-Aug-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use correct type for AllocatePages, AllocatePool Use enum efi_memory_type and enum_allocate_type in the definitions of the efi_allocate_pages(), efi_allocate_pool(). In the external UEFI API leave the type as int as the UEFI specification explicitely requires that enums use a 32bit type. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il> |
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b05667c |
|
16-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Merge memory map entries We currently do not combine memory entries that are adjacent and have the same attributes. The problem with that is that our memory map can easily grow multiple hundreds of entries in a simple UEFI Shell environment. So let's make sure we always combine all entries to make the memory map as small as possible. That way every other piece of code that loops through it should also gain some nice speed ups. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
14deb5e6 |
|
30-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "Revert "efi_loader: efi_allocate_pages is too restrictive"" This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710. Now that the underlying issue is fixed, we can revert the revert and hence restore the original EFI code. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
9b89183b |
|
14-Jul-2018 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
efi: Fix truncation of constant value Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"), sparse constantly complains about truncated constant value in efi.h: include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0) This can get quite noisy, preventing real issues to be noticed: $ make defconfig *** Default configuration is based on 'sandbox_defconfig' $ make C=2 -j12 2>&1 | grep truncates | wc -l 441 After the patch is applied: $ make C=2 -j12 2>&1 | grep truncates | wc -l 0 $ sparse --version v0.5.2 Following the suggestion of Heinrich Schuchardt, instead of only fixing the root-cause, I replaced the whole enum of _SHIFT values by ULL defines. This matches both the UEFI 2.7 spec and the Linux kernel implementation. Some ELF size comparison before and after the patch (gcc 7.3.0): efi-x86_payload64_defconfig: text data bss dec hex filename 407174 29432 278676 715282 aea12 u-boot.old 407152 29464 278676 715292 aea1c u-boot.new -22 +32 0 +10 efi-x86_payload32_defconfig: text data bss dec hex filename 447075 30308 280076 757459 b8ed3 u-boot.old 447053 30340 280076 757469 b8edd u-boot.new -22 +32 0 +10 Fixes: 867a6ac86dd8 ("efi: Add start-up library code") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
fa995d0d |
|
06-Aug-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid NULL dereference in efi_get_memory_map() We should only dereference parameter memory_map_size after checking that it is valid. Fixes: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ccfc78b8 |
|
02-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "efi_loader: efi_allocate_pages is too restrictive" This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for example when running test/py. Reverting this change isn't optimal, but at least restores TX1 to a working state. In the future, we should: a) Fix whatever problem causes the crash with this patch applied. This needs further discussion, so isn't something we can immediately do. b) Undo the revert; re-apply the original patch to efi_allocate_pages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1fcb7ea2 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check map_key in ExitBootServices The UEFI spec requires that the memory map key is checked in ExitBootServices(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
8e835554 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters of GetMemoryMap Check the parameters of boottime service GetMemoryMap(). Return EFI_INVALID_PARAMETER where required by the UEFI spec. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4d5e071e |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters in memory allocation If no pointer is provided throw an error. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
282a06cb |
|
18-Jun-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Expose U-Boot addresses in memory map for sandbox We currently expose host addresses in the EFI memory map. That can be bad if we ever want to use sandbox to boot strap a real kernel, because then the kernel would fetch its memory table from our host virtual address map. But to make that use case work, we would need to have full control over the address space the EFI application sees. So let's expose only U-Boot addresses to the guest until we get to the point of allocation. EFI's allocation functions are fun - they can take U-Boot addresses as input values for hints and return host addresses as allocation results through the same uint64_t * parameter. So we need to be extra careful on what to pass in when. With this patch I am successfully able to run the efi selftest suite as well as grub.efi on aarch64. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
69259b83 |
|
18-Jun-2018 |
Simon Glass <sjg@chromium.org> |
efi: sandbox: Adjust memory usage for sandbox With sandbox the U-Boot code is not mapped into the sandbox memory range so does not need to be excluded when allocating EFI memory. Update the EFI memory init code to take account of that. Signed-off-by: Simon Glass <sjg@chromium.org> [agraf: Remove map_sysmem() call and header reference] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
aa909462 |
|
18-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_allocate_pages is too restrictive When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory. There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: use -1ULL instead] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
32826140 |
|
27-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_mem_carve_out should return s64 efi_mem_carve_out() is used to remove memory pages from a mapping. As the number of pages to be removed is a 64bit type the return type should be 64bit too. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
e09159c8 |
|
26-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid anonymous constants for AllocatePages Do not use anonymous constants when calling efi_allocage_pages. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1f0532ca |
|
27-Apr-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove unnecessary include asm/global_data.h is already included via common.h. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f739fcd8 |
|
07-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert a few files that were missed before As part of the main conversion a few files were missed. These files had additional whitespace after the '*' and before the SPDX tag and my previous regex was too strict. This time I did a grep for all SPDX tags and then filtered out anything that matched the correct styles. Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style") Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bdecaebd |
|
08-Mar-2018 |
Simon Glass <sjg@chromium.org> |
efi: Correct header order in efi_memory The headers are not in the correct order. Fix this. Also drop libfdt_env.h since it is not needed. Signed-off-by: Simon Glass <sjg@chromium.org> Rebased Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7c92fd69 |
|
30-Jan-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use constants in efi_allocate_pages() Using the existing predefined constants is less error prone and makes the code easier to read. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b08c8c48 |
|
04-Mar-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h> Thomas reported U-Boot failed to build host tools if libfdt-devel package is installed because tools include libfdt headers from /usr/include/ instead of using internal ones. This commit moves the header code: include/libfdt.h -> include/linux/libfdt.h include/libfdt_env.h -> include/linux/libfdt_env.h and replaces include directives: #include <libfdt.h> -> #include <linux/libfdt.h> #include <libfdt_env.h> -> #include <linux/libfdt_env.h> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
474a6f5a |
|
04-Dec-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: add comments to memory functions Add comments describing memory functions. Fix the formatting of a function declaration. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f5a2a938 |
|
06-Nov-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: consistently use efi_uintn_t in boot services Consistenly use efi_uintn_t wherever the UEFI spec uses UINTN in boot services interfaces. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
946160f3 |
|
13-Sep-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: make pool allocations cacheline aligned This avoids printf() spam about file reads (such as loading an image) into unaligned buffers (and the associated memcpy()). And generally seems like a good idea. Signed-off-by: Rob Clark <robdclark@gmail.com> [agraf: use __aligned] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
a1b24823 |
|
26-Jul-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: fix bug in efi_get_memory_map When booting shim -> fallback -> shim -> grub -> linux the memory map is a bit larger than the size linux passes in on the first call. But in the EFI_BUFFER_TOO_SMALL case we were not passing back the updated size to linux so it would loop forever. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c6e3c3e6 |
|
21-Jul-2017 |
xypron.glpk@gmx.de <xypron.glpk@gmx.de> |
efi_memory: return MapKey efi_get_memory_map should set a defined value for map_key. We later can introduce the test against this value in efi_exit_boot_services as required by the UEFI standard. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
0ecba5db |
|
21-Jul-2017 |
xypron.glpk@gmx.de <xypron.glpk@gmx.de> |
efi_memory: do parameter checks first The parameter checks should be done first. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
71275a3e |
|
14-Jul-2017 |
xypron.glpk@gmx.de <xypron.glpk@gmx.de> |
efi_memory: avoid NULL dereference in efi_free_pool If efi_free_pool is called with argument NULL an illegal memory access occurs. So let's check the parameter on entry. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42633745 |
|
06-Mar-2017 |
York Sun <york.sun@nxp.com> |
efi: Add a hook to allow adding memory mapping Instead of adding all memory banks, add a hook so individual SoC/board can has its own implementation. Signed-off-by: York Sun <york.sun@nxp.com> CC: Alexander Graf <agraf@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
511d0b97 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Do not leak memory when unlinking a mapping As soon as a mapping is unlinked from the list, there are no further references to it, so it should be freed. If it not unlinked, update the start address and length. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b6a95172 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Keep memory mapping sorted when splitting an entry The code assumes sorted mappings in descending address order. When splitting a mapping, insert the new part next to the current mapping. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b61d857b |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Readd freed pages to memory pool 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42417bc8 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Track size of pool allocations to allow freeing 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ead1274b |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Move efi_allocate_pool implementation to efi_memory.c 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
bdf5c1b3 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Fix memory map size check to avoid out-of-bounds access The current efi_get_memory_map() function overwrites the map_size property before reading its value. That way the sanity check whether our memory map fits into the given array always succeeds, potentially overwriting arbitrary payload memory. This patch moves the property update write after its sanity check, so that the check actually verifies the correct value. So far this has not triggered any known bugs, but we're better off safe than sorry. If the buffer is to small, the returned memory_map_size indicates the required size to the caller. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
852efbf5 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Update description of internal efi_mem_carve_out In 74c16acce30bb882ad5951829d8dafef8eea564c the return values where changed, but the description was kept. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4c02c11d |
|
05-Sep-2016 |
Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
efi_loader: provide efi_mem_desc version Provide version of struct efi_mem_desc in efi_get_memory_map(). EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines memory descriptor version to 1. Linux kernel also expects descriptor version to be 1 and prints following warning during boot if its not: Unexpected EFI_MEMORY_DESCRIPTOR version 0 Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
#
c933ed94 |
|
16-Jul-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Add debug output for efi_add_memory_map() Tracing the arguments has been helpful for pinpointing overflows. Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
74c16acc |
|
26-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Don't allocate from memory holes When a payload calls our memory allocator with the exact address hint, we happily allocate memory from completely unpopulated regions. Payloads however expect this to only succeed if they would be allocating from free conventional memory. This patch makes the logic behind those checks a bit more obvious and ensures that we always allocate from known good free conventional memory regions if we want to allocate ram. Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
edcef3ba |
|
02-Jun-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Move to normal debug infrastructure 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> |
#
51735ae0 |
|
11-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Add bounce buffer support 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: Alexander Graf <agraf@suse.de> |
#
dede284d |
|
13-Apr-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Handle memory overflows 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> |
#
cee752fa |
|
11-Apr-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
38ce65e1 |
|
30-Mar-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Always allocate the highest available address 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> |
#
5d00995c |
|
03-Mar-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
ebdea88d |
|
11-Oct-2021 |
Ilias Apalodimas <ilias.apalodimas@linaro.org> |
efi_loader: Fix loaded image alignment We are ignoring the alignment communicated via the PE/COFF header. Starting 5.10 the Linux kernel will loudly complain about it. For more details look at [1] (in linux kernel). So add a function that can allocate aligned EFI memory and use it for our relocated loaded image. [1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Vincent Stehlé <vincent.stehle@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
49d225e7 |
|
17-Aug-2021 |
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
efi_loader: use correct type for AllocatePages, AllocatePool Use enum efi_memory_type and enum_allocate_type in the definitions of the efi_allocate_pages(), efi_allocate_pool(). In the external UEFI API leave the type as int as the UEFI specification explicitely requires that enums use a 32bit type. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il> |
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b05667c |
|
16-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Merge memory map entries We currently do not combine memory entries that are adjacent and have the same attributes. The problem with that is that our memory map can easily grow multiple hundreds of entries in a simple UEFI Shell environment. So let's make sure we always combine all entries to make the memory map as small as possible. That way every other piece of code that loops through it should also gain some nice speed ups. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
14deb5e6 |
|
30-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "Revert "efi_loader: efi_allocate_pages is too restrictive"" This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710. Now that the underlying issue is fixed, we can revert the revert and hence restore the original EFI code. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
9b89183b |
|
14-Jul-2018 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
efi: Fix truncation of constant value Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"), sparse constantly complains about truncated constant value in efi.h: include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0) This can get quite noisy, preventing real issues to be noticed: $ make defconfig *** Default configuration is based on 'sandbox_defconfig' $ make C=2 -j12 2>&1 | grep truncates | wc -l 441 After the patch is applied: $ make C=2 -j12 2>&1 | grep truncates | wc -l 0 $ sparse --version v0.5.2 Following the suggestion of Heinrich Schuchardt, instead of only fixing the root-cause, I replaced the whole enum of _SHIFT values by ULL defines. This matches both the UEFI 2.7 spec and the Linux kernel implementation. Some ELF size comparison before and after the patch (gcc 7.3.0): efi-x86_payload64_defconfig: text data bss dec hex filename 407174 29432 278676 715282 aea12 u-boot.old 407152 29464 278676 715292 aea1c u-boot.new -22 +32 0 +10 efi-x86_payload32_defconfig: text data bss dec hex filename 447075 30308 280076 757459 b8ed3 u-boot.old 447053 30340 280076 757469 b8edd u-boot.new -22 +32 0 +10 Fixes: 867a6ac86dd8 ("efi: Add start-up library code") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
fa995d0d |
|
06-Aug-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid NULL dereference in efi_get_memory_map() We should only dereference parameter memory_map_size after checking that it is valid. Fixes: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ccfc78b8 |
|
02-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "efi_loader: efi_allocate_pages is too restrictive" This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for example when running test/py. Reverting this change isn't optimal, but at least restores TX1 to a working state. In the future, we should: a) Fix whatever problem causes the crash with this patch applied. This needs further discussion, so isn't something we can immediately do. b) Undo the revert; re-apply the original patch to efi_allocate_pages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1fcb7ea2 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check map_key in ExitBootServices The UEFI spec requires that the memory map key is checked in ExitBootServices(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
8e835554 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters of GetMemoryMap Check the parameters of boottime service GetMemoryMap(). Return EFI_INVALID_PARAMETER where required by the UEFI spec. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4d5e071e |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters in memory allocation If no pointer is provided throw an error. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
282a06cb |
|
18-Jun-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Expose U-Boot addresses in memory map for sandbox We currently expose host addresses in the EFI memory map. That can be bad if we ever want to use sandbox to boot strap a real kernel, because then the kernel would fetch its memory table from our host virtual address map. But to make that use case work, we would need to have full control over the address space the EFI application sees. So let's expose only U-Boot addresses to the guest until we get to the point of allocation. EFI's allocation functions are fun - they can take U-Boot addresses as input values for hints and return host addresses as allocation results through the same uint64_t * parameter. So we need to be extra careful on what to pass in when. With this patch I am successfully able to run the efi selftest suite as well as grub.efi on aarch64. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
69259b83 |
|
18-Jun-2018 |
Simon Glass <sjg@chromium.org> |
efi: sandbox: Adjust memory usage for sandbox With sandbox the U-Boot code is not mapped into the sandbox memory range so does not need to be excluded when allocating EFI memory. Update the EFI memory init code to take account of that. Signed-off-by: Simon Glass <sjg@chromium.org> [agraf: Remove map_sysmem() call and header reference] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
aa909462 |
|
18-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_allocate_pages is too restrictive When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory. There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: use -1ULL instead] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
32826140 |
|
27-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_mem_carve_out should return s64 efi_mem_carve_out() is used to remove memory pages from a mapping. As the number of pages to be removed is a 64bit type the return type should be 64bit too. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
e09159c8 |
|
26-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid anonymous constants for AllocatePages Do not use anonymous constants when calling efi_allocage_pages. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1f0532ca |
|
27-Apr-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove unnecessary include asm/global_data.h is already included via common.h. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f739fcd8 |
|
07-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert a few files that were missed before As part of the main conversion a few files were missed. These files had additional whitespace after the '*' and before the SPDX tag and my previous regex was too strict. This time I did a grep for all SPDX tags and then filtered out anything that matched the correct styles. Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style") Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bdecaebd |
|
08-Mar-2018 |
Simon Glass <sjg@chromium.org> |
efi: Correct header order in efi_memory The headers are not in the correct order. Fix this. Also drop libfdt_env.h since it is not needed. Signed-off-by: Simon Glass <sjg@chromium.org> Rebased Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7c92fd69 |
|
30-Jan-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use constants in efi_allocate_pages() Using the existing predefined constants is less error prone and makes the code easier to read. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b08c8c48 |
|
04-Mar-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h> Thomas reported U-Boot failed to build host tools if libfdt-devel package is installed because tools include libfdt headers from /usr/include/ instead of using internal ones. This commit moves the header code: include/libfdt.h -> include/linux/libfdt.h include/libfdt_env.h -> include/linux/libfdt_env.h and replaces include directives: #include <libfdt.h> -> #include <linux/libfdt.h> #include <libfdt_env.h> -> #include <linux/libfdt_env.h> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
474a6f5a |
|
04-Dec-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: add comments to memory functions Add comments describing memory functions. Fix the formatting of a function declaration. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f5a2a938 |
|
06-Nov-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: consistently use efi_uintn_t in boot services Consistenly use efi_uintn_t wherever the UEFI spec uses UINTN in boot services interfaces. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
946160f3 |
|
13-Sep-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: make pool allocations cacheline aligned This avoids printf() spam about file reads (such as loading an image) into unaligned buffers (and the associated memcpy()). And generally seems like a good idea. Signed-off-by: Rob Clark <robdclark@gmail.com> [agraf: use __aligned] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
a1b24823 |
|
26-Jul-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: fix bug in efi_get_memory_map When booting shim -> fallback -> shim -> grub -> linux the memory map is a bit larger than the size linux passes in on the first call. But in the EFI_BUFFER_TOO_SMALL case we were not passing back the updated size to linux so it would loop forever. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c6e3c3e6 |
|
21-Jul-2017 |
xypron.glpk@gmx.de <xypron.glpk@gmx.de> |
efi_memory: return MapKey efi_get_memory_map should set a defined value for map_key. We later can introduce the test against this value in efi_exit_boot_services as required by the UEFI standard. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
0ecba5db |
|
21-Jul-2017 |
xypron.glpk@gmx.de <xypron.glpk@gmx.de> |
efi_memory: do parameter checks first The parameter checks should be done first. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
71275a3e |
|
14-Jul-2017 |
xypron.glpk@gmx.de <xypron.glpk@gmx.de> |
efi_memory: avoid NULL dereference in efi_free_pool If efi_free_pool is called with argument NULL an illegal memory access occurs. So let's check the parameter on entry. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42633745 |
|
06-Mar-2017 |
York Sun <york.sun@nxp.com> |
efi: Add a hook to allow adding memory mapping Instead of adding all memory banks, add a hook so individual SoC/board can has its own implementation. Signed-off-by: York Sun <york.sun@nxp.com> CC: Alexander Graf <agraf@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
511d0b97 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Do not leak memory when unlinking a mapping As soon as a mapping is unlinked from the list, there are no further references to it, so it should be freed. If it not unlinked, update the start address and length. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b6a95172 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Keep memory mapping sorted when splitting an entry The code assumes sorted mappings in descending address order. When splitting a mapping, insert the new part next to the current mapping. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b61d857b |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Readd freed pages to memory pool 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42417bc8 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Track size of pool allocations to allow freeing 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ead1274b |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Move efi_allocate_pool implementation to efi_memory.c 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
bdf5c1b3 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Fix memory map size check to avoid out-of-bounds access The current efi_get_memory_map() function overwrites the map_size property before reading its value. That way the sanity check whether our memory map fits into the given array always succeeds, potentially overwriting arbitrary payload memory. This patch moves the property update write after its sanity check, so that the check actually verifies the correct value. So far this has not triggered any known bugs, but we're better off safe than sorry. If the buffer is to small, the returned memory_map_size indicates the required size to the caller. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
852efbf5 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Update description of internal efi_mem_carve_out In 74c16acce30bb882ad5951829d8dafef8eea564c the return values where changed, but the description was kept. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4c02c11d |
|
05-Sep-2016 |
Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
efi_loader: provide efi_mem_desc version Provide version of struct efi_mem_desc in efi_get_memory_map(). EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines memory descriptor version to 1. Linux kernel also expects descriptor version to be 1 and prints following warning during boot if its not: Unexpected EFI_MEMORY_DESCRIPTOR version 0 Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
#
c933ed94 |
|
16-Jul-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Add debug output for efi_add_memory_map() Tracing the arguments has been helpful for pinpointing overflows. Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
74c16acc |
|
26-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Don't allocate from memory holes When a payload calls our memory allocator with the exact address hint, we happily allocate memory from completely unpopulated regions. Payloads however expect this to only succeed if they would be allocating from free conventional memory. This patch makes the logic behind those checks a bit more obvious and ensures that we always allocate from known good free conventional memory regions if we want to allocate ram. Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
edcef3ba |
|
02-Jun-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Move to normal debug infrastructure 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> |
#
51735ae0 |
|
11-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Add bounce buffer support 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: Alexander Graf <agraf@suse.de> |
#
dede284d |
|
13-Apr-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Handle memory overflows 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> |
#
cee752fa |
|
11-Apr-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
38ce65e1 |
|
30-Mar-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Always allocate the highest available address 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> |
#
5d00995c |
|
03-Mar-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
49d225e7 |
|
17-Aug-2021 |
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
efi_loader: use correct type for AllocatePages, AllocatePool Use enum efi_memory_type and enum_allocate_type in the definitions of the efi_allocate_pages(), efi_allocate_pool(). In the external UEFI API leave the type as int as the UEFI specification explicitely requires that enums use a 32bit type. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> |
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> |
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il> |
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7b05667c |
|
16-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Merge memory map entries We currently do not combine memory entries that are adjacent and have the same attributes. The problem with that is that our memory map can easily grow multiple hundreds of entries in a simple UEFI Shell environment. So let's make sure we always combine all entries to make the memory map as small as possible. That way every other piece of code that loops through it should also gain some nice speed ups. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
14deb5e6 |
|
30-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "Revert "efi_loader: efi_allocate_pages is too restrictive"" This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710. Now that the underlying issue is fixed, we can revert the revert and hence restore the original EFI code. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
9b89183b |
|
14-Jul-2018 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
efi: Fix truncation of constant value Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"), sparse constantly complains about truncated constant value in efi.h: include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0) This can get quite noisy, preventing real issues to be noticed: $ make defconfig *** Default configuration is based on 'sandbox_defconfig' $ make C=2 -j12 2>&1 | grep truncates | wc -l 441 After the patch is applied: $ make C=2 -j12 2>&1 | grep truncates | wc -l 0 $ sparse --version v0.5.2 Following the suggestion of Heinrich Schuchardt, instead of only fixing the root-cause, I replaced the whole enum of _SHIFT values by ULL defines. This matches both the UEFI 2.7 spec and the Linux kernel implementation. Some ELF size comparison before and after the patch (gcc 7.3.0): efi-x86_payload64_defconfig: text data bss dec hex filename 407174 29432 278676 715282 aea12 u-boot.old 407152 29464 278676 715292 aea1c u-boot.new -22 +32 0 +10 efi-x86_payload32_defconfig: text data bss dec hex filename 447075 30308 280076 757459 b8ed3 u-boot.old 447053 30340 280076 757469 b8edd u-boot.new -22 +32 0 +10 Fixes: 867a6ac86dd8 ("efi: Add start-up library code") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
fa995d0d |
|
06-Aug-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid NULL dereference in efi_get_memory_map() We should only dereference parameter memory_map_size after checking that it is valid. Fixes: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ccfc78b8 |
|
02-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "efi_loader: efi_allocate_pages is too restrictive" This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for example when running test/py. Reverting this change isn't optimal, but at least restores TX1 to a working state. In the future, we should: a) Fix whatever problem causes the crash with this patch applied. This needs further discussion, so isn't something we can immediately do. b) Undo the revert; re-apply the original patch to efi_allocate_pages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1fcb7ea2 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check map_key in ExitBootServices The UEFI spec requires that the memory map key is checked in ExitBootServices(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
8e835554 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters of GetMemoryMap Check the parameters of boottime service GetMemoryMap(). Return EFI_INVALID_PARAMETER where required by the UEFI spec. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4d5e071e |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters in memory allocation If no pointer is provided throw an error. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
282a06cb |
|
18-Jun-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Expose U-Boot addresses in memory map for sandbox We currently expose host addresses in the EFI memory map. That can be bad if we ever want to use sandbox to boot strap a real kernel, because then the kernel would fetch its memory table from our host virtual address map. But to make that use case work, we would need to have full control over the address space the EFI application sees. So let's expose only U-Boot addresses to the guest until we get to the point of allocation. EFI's allocation functions are fun - they can take U-Boot addresses as input values for hints and return host addresses as allocation results through the same uint64_t * parameter. So we need to be extra careful on what to pass in when. With this patch I am successfully able to run the efi selftest suite as well as grub.efi on aarch64. Signed-off-by: Alexander Graf <agraf@suse.de> |
#
69259b83 |
|
18-Jun-2018 |
Simon Glass <sjg@chromium.org> |
efi: sandbox: Adjust memory usage for sandbox With sandbox the U-Boot code is not mapped into the sandbox memory range so does not need to be excluded when allocating EFI memory. Update the EFI memory init code to take account of that. Signed-off-by: Simon Glass <sjg@chromium.org> [agraf: Remove map_sysmem() call and header reference] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
aa909462 |
|
18-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_allocate_pages is too restrictive When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory. There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: use -1ULL instead] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
32826140 |
|
27-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_mem_carve_out should return s64 efi_mem_carve_out() is used to remove memory pages from a mapping. As the number of pages to be removed is a 64bit type the return type should be 64bit too. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
e09159c8 |
|
26-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid anonymous constants for AllocatePages Do not use anonymous constants when calling efi_allocage_pages. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
1f0532ca |
|
27-Apr-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove unnecessary include asm/global_data.h is already included via common.h. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f739fcd8 |
|
07-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert a few files that were missed before As part of the main conversion a few files were missed. These files had additional whitespace after the '*' and before the SPDX tag and my previous regex was too strict. This time I did a grep for all SPDX tags and then filtered out anything that matched the correct styles. Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style") Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com> |
#
bdecaebd |
|
08-Mar-2018 |
Simon Glass <sjg@chromium.org> |
efi: Correct header order in efi_memory The headers are not in the correct order. Fix this. Also drop libfdt_env.h since it is not needed. Signed-off-by: Simon Glass <sjg@chromium.org> Rebased Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
7c92fd69 |
|
30-Jan-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use constants in efi_allocate_pages() Using the existing predefined constants is less error prone and makes the code easier to read. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b08c8c48 |
|
04-Mar-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h> Thomas reported U-Boot failed to build host tools if libfdt-devel package is installed because tools include libfdt headers from /usr/include/ instead of using internal ones. This commit moves the header code: include/libfdt.h -> include/linux/libfdt.h include/libfdt_env.h -> include/linux/libfdt_env.h and replaces include directives: #include <libfdt.h> -> #include <linux/libfdt.h> #include <libfdt_env.h> -> #include <linux/libfdt_env.h> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> |
#
474a6f5a |
|
04-Dec-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: add comments to memory functions Add comments describing memory functions. Fix the formatting of a function declaration. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
f5a2a938 |
|
06-Nov-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: consistently use efi_uintn_t in boot services Consistenly use efi_uintn_t wherever the UEFI spec uses UINTN in boot services interfaces. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
946160f3 |
|
13-Sep-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: make pool allocations cacheline aligned This avoids printf() spam about file reads (such as loading an image) into unaligned buffers (and the associated memcpy()). And generally seems like a good idea. Signed-off-by: Rob Clark <robdclark@gmail.com> [agraf: use __aligned] Signed-off-by: Alexander Graf <agraf@suse.de> |
#
a1b24823 |
|
26-Jul-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: fix bug in efi_get_memory_map When booting shim -> fallback -> shim -> grub -> linux the memory map is a bit larger than the size linux passes in on the first call. But in the EFI_BUFFER_TOO_SMALL case we were not passing back the updated size to linux so it would loop forever. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
c6e3c3e6 |
|
21-Jul-2017 |
xypron.glpk@gmx.de <xypron.glpk@gmx.de> |
efi_memory: return MapKey efi_get_memory_map should set a defined value for map_key. We later can introduce the test against this value in efi_exit_boot_services as required by the UEFI standard. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
0ecba5db |
|
21-Jul-2017 |
xypron.glpk@gmx.de <xypron.glpk@gmx.de> |
efi_memory: do parameter checks first The parameter checks should be done first. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
71275a3e |
|
14-Jul-2017 |
xypron.glpk@gmx.de <xypron.glpk@gmx.de> |
efi_memory: avoid NULL dereference in efi_free_pool If efi_free_pool is called with argument NULL an illegal memory access occurs. So let's check the parameter on entry. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42633745 |
|
06-Mar-2017 |
York Sun <york.sun@nxp.com> |
efi: Add a hook to allow adding memory mapping Instead of adding all memory banks, add a hook so individual SoC/board can has its own implementation. Signed-off-by: York Sun <york.sun@nxp.com> CC: Alexander Graf <agraf@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
511d0b97 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Do not leak memory when unlinking a mapping As soon as a mapping is unlinked from the list, there are no further references to it, so it should be freed. If it not unlinked, update the start address and length. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b6a95172 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Keep memory mapping sorted when splitting an entry The code assumes sorted mappings in descending address order. When splitting a mapping, insert the new part next to the current mapping. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
b61d857b |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Readd freed pages to memory pool 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
42417bc8 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Track size of pool allocations to allow freeing 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
ead1274b |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Move efi_allocate_pool implementation to efi_memory.c 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
bdf5c1b3 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Fix memory map size check to avoid out-of-bounds access The current efi_get_memory_map() function overwrites the map_size property before reading its value. That way the sanity check whether our memory map fits into the given array always succeeds, potentially overwriting arbitrary payload memory. This patch moves the property update write after its sanity check, so that the check actually verifies the correct value. So far this has not triggered any known bugs, but we're better off safe than sorry. If the buffer is to small, the returned memory_map_size indicates the required size to the caller. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
852efbf5 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Update description of internal efi_mem_carve_out In 74c16acce30bb882ad5951829d8dafef8eea564c the return values where changed, but the description was kept. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
4c02c11d |
|
05-Sep-2016 |
Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
efi_loader: provide efi_mem_desc version Provide version of struct efi_mem_desc in efi_get_memory_map(). EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines memory descriptor version to 1. Linux kernel also expects descriptor version to be 1 and prints following warning during boot if its not: Unexpected EFI_MEMORY_DESCRIPTOR version 0 Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
#
c933ed94 |
|
16-Jul-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Add debug output for efi_add_memory_map() Tracing the arguments has been helpful for pinpointing overflows. Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de> |
#
74c16acc |
|
26-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Don't allocate from memory holes When a payload calls our memory allocator with the exact address hint, we happily allocate memory from completely unpopulated regions. Payloads however expect this to only succeed if they would be allocating from free conventional memory. This patch makes the logic behind those checks a bit more obvious and ensures that we always allocate from known good free conventional memory regions if we want to allocate ram. Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de> |
#
edcef3ba |
|
02-Jun-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Move to normal debug infrastructure 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> |
#
51735ae0 |
|
11-May-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Add bounce buffer support 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: Alexander Graf <agraf@suse.de> |
#
dede284d |
|
13-Apr-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Handle memory overflows 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> |
#
cee752fa |
|
11-Apr-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
38ce65e1 |
|
30-Mar-2016 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Always allocate the highest available address 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> |
#
5d00995c |
|
03-Mar-2016 |
Alexander Graf <agraf@csgraf.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 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> |
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
db0f2984 |
|
05-Jan-2021 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove outdated TODO in efi_memory.c In efi_mem_sort() adjacent memory regions of same type are coalesced. Remove the remark "Merging of adjacent free regions is missing". Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ffbeafe7 |
|
28-Aug-2020 |
Maxim Uvarov <maxim.uvarov@linaro.org> |
efi_memory: refine overlap_only_ram description Refine text for overlap_only_ram description to match to what exactly flag does and aling description with other functions. Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
74b869ba |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze with the same meaning. Move it to menu 'General setup' so that we can use it for all architectures. Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for reserving memory in the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
714497e3 |
|
16-May-2020 |
Michael Walle <michael@walle.cc> |
efi_loader: round the memory area in efi_add_memory_map() Virtually all callers of this function do the rounding on their own. Some do it right, some don't. Instead of doing this in each caller, do the rounding in efi_add_memory_map(). Change the size parameter to bytes instead of pages and remove aligning and size calculation in all callers. There is no more need to make the original efi_add_memory_map() (which takes pages as size) available outside the module. Thus rename it to efi_add_memory_map_pg() and make it static to prevent further misuse outside the module. Signed-off-by: Michael Walle <michael@walle.cc> Add missing comma in sunxi_display.c. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b484296f |
|
11-Mar-2020 |
AKASHI Takahiro <takahiro.akashi@linaro.org> |
efi_loader: get_memory_map: return parameters whenever possible Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't set valid values to other parameters, descriptor_size and descriptor_version, except memory_map_size. Some efi applications, however, may use those value; in particular, xen uses descriptor_size to calculate a size of buffer to be allocated. While UEFI specification is ambiguous in this point, it would be better to address this issue proactively to maximize the compatibility with existing efi applications. With this patch, for example, xen.efi (and hence linux kernel) can be started via bootefi without modification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@csgraf.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h Move this function into init.h which seems to be designed for this sort of thing. Also update the header to declare struct global_data so that it can be included without global_data.h being needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7264e21f |
|
08-Nov-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: call add_u_boot_and_runtime() on sandbox On the sandbox we should mark the stack area as EFI runtime memory like we do on any other architecture. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b5b9eff2 |
|
03-Sep-2019 |
Park, Aiden <aiden.park@intel.com> |
efi_loader: Extract adding a conventional memory in separate routine Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park <aiden.park@intel.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
4be077b2 |
|
13-Jul-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix comment for struct efi_pool_allocation Change comment for struct efi_pool_allocation to match Sphinx style. Describe all structure fields. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
b225c92f |
|
14-Jul-2019 |
Bryan O'Donoghue <pure.logic@nexus-software.ie> |
efi_loader: Change return type of efi_add_memory_map() We currently have some inconsistent use of efi_add_memory_map() throughout the code. In particular the return value of efi_add_memory_map() is not interpreted the same way by various users in the codebase. This patch does the following: - Changes efi_add_memory_map() to return efi_status_t. - Adds a method description to efi_add_memory_map(). - Changes efi_add_memory_map() to return EFI_SUCCESS - Returns non-zero for error in efi_add_memory_map() - Updates efi_allocate_pages() to new efi_add_memory_map() - Updates efi_free_pages() to new efi_add_memory_map() - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map() - Updates efi_add_runtime_mmio() to new efi_add_memory_map() Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map") Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Alexander Graf <agraf@csgraf.de> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
0e22c7cb |
|
11-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocatePages() must accept addr == 0 It must be possible to allocate memory at address 0 with AllocatePages(). Move a NULL pointer check. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7eaa900e |
|
06-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: event signaling in ExitBootServices ExitBootServices() has to stop timer related activity before calling the events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our current implementation was stopping all other events. All events have to observe the task priority level. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e80474ad |
|
04-Jun-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: notify memory map changes When the memory map is changed signal events of the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event group. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
8ae39857 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: simplify efi_allocate_pages() Replace unnecessary control structures by using return statements. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f756fe83 |
|
11-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: AllocateAdress error handling If AllocatePages() is called with AllocateAddress, the UEFI spec requires to return EFI_NOT_FOUND in case the memory page does not exist. The UEFI SCT II 2017 spec additionally requires to return EFI_NOT_FOUND if the page is already allocated. Check that *Memory refers to an unallocated page. UEFI SCT II (2017): AllocatePages(), 5.1.2.1.9 - 5.1.2.1.10 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
735fd228 |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: out of resources in AllocatePages() According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if sufficient memory is not available. Change the return value. UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
7d3af58e |
|
10-May-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory address before freeing When we call FreePages() we essentially add memory to our memory map. We shouldn't do this for memory that does not exit. Check if the memory that is to be freed via FreePages() or FreePool() is in our memory map and is not EFI_CONVENTIONAL_MEMORY. This check is mandated by the UEFI specification. Cf. UEFI SCT II (2017), 3.2.2 FreePages(), 5.1.2.1 - 5.1.2.2 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e00b82db |
|
25-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: FreePages() must fail with pages = 0 The UEFI spec requires that freeing of pages fails if the number of pages to be freed is 'invalid'. Check that it is not zero. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
f12bcc91 |
|
22-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check memory type in AllocatePages() The UEFI specification prescribes that AllocatePages() checks the memory type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
9631fa0f |
|
11-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: update virtual address in efi_mem_carve_out Handle virtual address in efi_mem_carve_out() function when a new region is created to avoid issue in EFI memory map. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> At boottime physical and virtual addressed have to be the same. This allowed to simplify the proposed logic. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
e301e024 |
|
04-Apr-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: EFI_PRINT instead of debug for memory services For debug messages inside EFI API functions we should use the EFI_PRINT macro which gives us well aligned output like: EFI: Entry efi_allocate_pool_ext(4, 14, 000000007edd7718) EFI: efi_add_memory_map: 0x7dcfa000 0x1 4 yes EFI: Exit: efi_allocate_pool_ext: 0 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
2c3ec289 |
|
25-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: sanity checks when freeing memory Use a checksum to validate that efi_free_pool() is only called for memory allocated by efi_allocated_pool(). Add a plausibility check to efi_free_pages() checking that the address passed is page aligned. Update related function comments to match Sphinx style. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
306b1671 |
|
18-Mar-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct parameter size in efi_allocate_pool efi_allocate_pages() expects a (uint64_t *) pointer to pass the address of the assigned memory. If we pass the address of a pointer here, an illegal memory access occurs on 32bit systems. Fixes: 282a06cbcae8 ("efi_loader: Expose U-Boot addresses in memory map for sandbox") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
#
23f5f4ab |
|
05-Jan-2019 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: fix memory allocation on sandbox Commit 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") introduced a comparison between RAM top and RAM start that was not known at the time when the patch of commit 49759743bf09 ("efi_loader: eliminate sandbox addresses") was written. The sandbox uses an address space that is only relevant in the sandbox context. We have to map ram_top from the sandbox address space to the physical address space before using it in the EFI subsystem. Fixes: 49759743bf09 ("efi_loader: eliminate sandbox addresses") Fixes: 7b78d6438a2b ("efi_loader: Reserve unaccessible memory") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7a82c305 |
|
17-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Align runtime section to 64kb The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c3772ca1 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: macro efi_size_in_pages() When allocating EFI memory pages the size in bytes has to be converted to pages. Provide a macro efi_size_in_pages() for this conversion. Use it in the EFI subsystem and correct related comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
49759743 |
|
18-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: eliminate sandbox addresses Do not use the sandbox's virtual address space for the internal structures of the memory map. This way we can eliminate a whole lot of unnecessary conversions. The only conversion remaining is the one when adding known memory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b78d643 |
|
30-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Reserve unaccessible memory On some systems, not all RAM may be usable within U-Boot. Maybe the memory maps are incomplete, maybe it's used as workaround for broken DMA. But whatever the reason may be, a platform can say that it does not wish to have its RAM accessed above a certain address by defining board_get_usable_ram_top(). In the efi_loader world, we ignored that hint, mostly because very few boards actually have real restrictions around this. So let's honor the board's wish to not access high addresses during boot time. The best way to do so is by indicating the respective pages as "allocated by firmware". That way, Operating Systems will still use the pages after boot, but before boot no allocation will use them. Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
|
#
108bdff8 |
|
12-Nov-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: correct efi_add_known_memory() If a memory bank is not EFI_PAGE_SIZE aligned efi_add_known_memory() the number of memory pages may be incorrectly calculated. We have to round up the start address and to round down the end address to determine which complete pages are provided by the memory bank. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c2e1ad70 |
|
04-Nov-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Ensure memory allocations are page aligned When the max_addr parameter of efi_find_free_memory() is within bounds of an existing map and fits the reservation, we just return that address as allocation value. That breaks however if max_addr is not page aligned. So ensure that it always comes to us page aligned, simplifying the allocation logic. Without this, I've seen breakage where we were allocating pages at -1U (32bit) which fits into a region that spans beyond 0x100000000. In that case, we would return 0xffffffff as a valid memory allocation, although we usually do guarantee they are all page aligned. Fix this by aligning the max address argument always. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7b05667c |
|
16-Sep-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Merge memory map entries We currently do not combine memory entries that are adjacent and have the same attributes. The problem with that is that our memory map can easily grow multiple hundreds of entries in a simple UEFI Shell environment. So let's make sure we always combine all entries to make the memory map as small as possible. That way every other piece of code that loops through it should also gain some nice speed ups. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
14deb5e6 |
|
30-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "Revert "efi_loader: efi_allocate_pages is too restrictive"" This reverts commit ccfc78b820e5e431c5bd73b072e7536a972e1710. Now that the underlying issue is fixed, we can revert the revert and hence restore the original EFI code. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
dee37fc9 |
|
06-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Remove <inttypes.h> includes and PRI* usages in printf() entirely In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
9b89183b |
|
14-Jul-2018 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
efi: Fix truncation of constant value Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"), sparse constantly complains about truncated constant value in efi.h: include/efi.h:176:35: warning: cast truncates bits from constant value (8000000000000000 becomes 0) This can get quite noisy, preventing real issues to be noticed: $ make defconfig *** Default configuration is based on 'sandbox_defconfig' $ make C=2 -j12 2>&1 | grep truncates | wc -l 441 After the patch is applied: $ make C=2 -j12 2>&1 | grep truncates | wc -l 0 $ sparse --version v0.5.2 Following the suggestion of Heinrich Schuchardt, instead of only fixing the root-cause, I replaced the whole enum of _SHIFT values by ULL defines. This matches both the UEFI 2.7 spec and the Linux kernel implementation. Some ELF size comparison before and after the patch (gcc 7.3.0): efi-x86_payload64_defconfig: text data bss dec hex filename 407174 29432 278676 715282 aea12 u-boot.old 407152 29464 278676 715292 aea1c u-boot.new -22 +32 0 +10 efi-x86_payload32_defconfig: text data bss dec hex filename 447075 30308 280076 757459 b8ed3 u-boot.old 447053 30340 280076 757469 b8edd u-boot.new -22 +32 0 +10 Fixes: 867a6ac86dd8 ("efi: Add start-up library code") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
fa995d0d |
|
06-Aug-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid NULL dereference in efi_get_memory_map() We should only dereference parameter memory_map_size after checking that it is valid. Fixes: 8e835554b36b ("efi_loader: check parameters of GetMemoryMap") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ccfc78b8 |
|
02-Aug-2018 |
Stephen Warren <swarren@nvidia.com> |
Revert "efi_loader: efi_allocate_pages is too restrictive" This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for example when running test/py. Reverting this change isn't optimal, but at least restores TX1 to a working state. In the future, we should: a) Fix whatever problem causes the crash with this patch applied. This needs further discussion, so isn't something we can immediately do. b) Undo the revert; re-apply the original patch to efi_allocate_pages. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
1fcb7ea2 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check map_key in ExitBootServices The UEFI spec requires that the memory map key is checked in ExitBootServices(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
8e835554 |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters of GetMemoryMap Check the parameters of boottime service GetMemoryMap(). Return EFI_INVALID_PARAMETER where required by the UEFI spec. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
4d5e071e |
|
01-Jul-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: check parameters in memory allocation If no pointer is provided throw an error. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
282a06cb |
|
18-Jun-2018 |
Alexander Graf <agraf@suse.de> |
efi_loader: Expose U-Boot addresses in memory map for sandbox We currently expose host addresses in the EFI memory map. That can be bad if we ever want to use sandbox to boot strap a real kernel, because then the kernel would fetch its memory table from our host virtual address map. But to make that use case work, we would need to have full control over the address space the EFI application sees. So let's expose only U-Boot addresses to the guest until we get to the point of allocation. EFI's allocation functions are fun - they can take U-Boot addresses as input values for hints and return host addresses as allocation results through the same uint64_t * parameter. So we need to be extra careful on what to pass in when. With this patch I am successfully able to run the efi selftest suite as well as grub.efi on aarch64. Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
69259b83 |
|
18-Jun-2018 |
Simon Glass <sjg@chromium.org> |
efi: sandbox: Adjust memory usage for sandbox With sandbox the U-Boot code is not mapped into the sandbox memory range so does not need to be excluded when allocating EFI memory. Update the EFI memory init code to take account of that. Signed-off-by: Simon Glass <sjg@chromium.org> [agraf: Remove map_sysmem() call and header reference] Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
aa909462 |
|
18-Jun-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_allocate_pages is too restrictive When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory. There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: use -1ULL instead] Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
32826140 |
|
27-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: efi_mem_carve_out should return s64 efi_mem_carve_out() is used to remove memory pages from a mapping. As the number of pages to be removed is a 64bit type the return type should be 64bit too. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
e09159c8 |
|
26-May-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: avoid anonymous constants for AllocatePages Do not use anonymous constants when calling efi_allocage_pages. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
1f0532ca |
|
27-Apr-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: remove unnecessary include asm/global_data.h is already included via common.h. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
f739fcd8 |
|
07-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert a few files that were missed before As part of the main conversion a few files were missed. These files had additional whitespace after the '*' and before the SPDX tag and my previous regex was too strict. This time I did a grep for all SPDX tags and then filtered out anything that matched the correct styles. Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style") Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
bdecaebd |
|
08-Mar-2018 |
Simon Glass <sjg@chromium.org> |
efi: Correct header order in efi_memory The headers are not in the correct order. Fix this. Also drop libfdt_env.h since it is not needed. Signed-off-by: Simon Glass <sjg@chromium.org> Rebased Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
7c92fd69 |
|
30-Jan-2018 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: use constants in efi_allocate_pages() Using the existing predefined constants is less error prone and makes the code easier to read. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b08c8c48 |
|
04-Mar-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h> Thomas reported U-Boot failed to build host tools if libfdt-devel package is installed because tools include libfdt headers from /usr/include/ instead of using internal ones. This commit moves the header code: include/libfdt.h -> include/linux/libfdt.h include/libfdt_env.h -> include/linux/libfdt_env.h and replaces include directives: #include <libfdt.h> -> #include <linux/libfdt.h> #include <libfdt_env.h> -> #include <linux/libfdt_env.h> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
474a6f5a |
|
04-Dec-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: add comments to memory functions Add comments describing memory functions. Fix the formatting of a function declaration. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
f5a2a938 |
|
06-Nov-2017 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
efi_loader: consistently use efi_uintn_t in boot services Consistenly use efi_uintn_t wherever the UEFI spec uses UINTN in boot services interfaces. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
946160f3 |
|
13-Sep-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: make pool allocations cacheline aligned This avoids printf() spam about file reads (such as loading an image) into unaligned buffers (and the associated memcpy()). And generally seems like a good idea. Signed-off-by: Rob Clark <robdclark@gmail.com> [agraf: use __aligned] Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
a1b24823 |
|
26-Jul-2017 |
Rob Clark <robdclark@gmail.com> |
efi_loader: fix bug in efi_get_memory_map When booting shim -> fallback -> shim -> grub -> linux the memory map is a bit larger than the size linux passes in on the first call. But in the EFI_BUFFER_TOO_SMALL case we were not passing back the updated size to linux so it would loop forever. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
c6e3c3e6 |
|
21-Jul-2017 |
xypron.glpk@gmx.de <xypron.glpk@gmx.de> |
efi_memory: return MapKey efi_get_memory_map should set a defined value for map_key. We later can introduce the test against this value in efi_exit_boot_services as required by the UEFI standard. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
0ecba5db |
|
21-Jul-2017 |
xypron.glpk@gmx.de <xypron.glpk@gmx.de> |
efi_memory: do parameter checks first The parameter checks should be done first. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
71275a3e |
|
14-Jul-2017 |
xypron.glpk@gmx.de <xypron.glpk@gmx.de> |
efi_memory: avoid NULL dereference in efi_free_pool If efi_free_pool is called with argument NULL an illegal memory access occurs. So let's check the parameter on entry. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
42633745 |
|
06-Mar-2017 |
York Sun <york.sun@nxp.com> |
efi: Add a hook to allow adding memory mapping Instead of adding all memory banks, add a hook so individual SoC/board can has its own implementation. Signed-off-by: York Sun <york.sun@nxp.com> CC: Alexander Graf <agraf@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de>
|
#
511d0b97 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Do not leak memory when unlinking a mapping As soon as a mapping is unlinked from the list, there are no further references to it, so it should be freed. If it not unlinked, update the start address and length. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b6a95172 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Keep memory mapping sorted when splitting an entry The code assumes sorted mappings in descending address order. When splitting a mapping, insert the new part next to the current mapping. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
b61d857b |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Readd freed pages to memory pool 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
42417bc8 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Track size of pool allocations to allow freeing 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
ead1274b |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Move efi_allocate_pool implementation to efi_memory.c 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: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
bdf5c1b3 |
|
09-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Fix memory map size check to avoid out-of-bounds access The current efi_get_memory_map() function overwrites the map_size property before reading its value. That way the sanity check whether our memory map fits into the given array always succeeds, potentially overwriting arbitrary payload memory. This patch moves the property update write after its sanity check, so that the check actually verifies the correct value. So far this has not triggered any known bugs, but we're better off safe than sorry. If the buffer is to small, the returned memory_map_size indicates the required size to the caller. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
852efbf5 |
|
01-Oct-2016 |
Stefan Brüns <stefan.bruens@rwth-aachen.de> |
efi_loader: Update description of internal efi_mem_carve_out In 74c16acce30bb882ad5951829d8dafef8eea564c the return values where changed, but the description was kept. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
4c02c11d |
|
05-Sep-2016 |
Mian Yousaf Kaukab <yousaf.kaukab@gmail.com> |
efi_loader: provide efi_mem_desc version Provide version of struct efi_mem_desc in efi_get_memory_map(). EFI_BOOT_SERVICES.GetMemoryMap() in UEFI specification v2.6 defines memory descriptor version to 1. Linux kernel also expects descriptor version to be 1 and prints following warning during boot if its not: Unexpected EFI_MEMORY_DESCRIPTOR version 0 Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@gmail.com>
|
#
c933ed94 |
|
16-Jul-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Add debug output for efi_add_memory_map() Tracing the arguments has been helpful for pinpointing overflows. Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alexander Graf <agraf@suse.de>
|
#
74c16acc |
|
26-May-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Don't allocate from memory holes When a payload calls our memory allocator with the exact address hint, we happily allocate memory from completely unpopulated regions. Payloads however expect this to only succeed if they would be allocating from free conventional memory. This patch makes the logic behind those checks a bit more obvious and ensures that we always allocate from known good free conventional memory regions if we want to allocate ram. Reported-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Alexander Graf <agraf@suse.de>
|
#
edcef3ba |
|
02-Jun-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Move to normal debug infrastructure 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>
|
#
51735ae0 |
|
11-May-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Add bounce buffer support 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: Alexander Graf <agraf@suse.de>
|
#
dede284d |
|
13-Apr-2016 |
Andreas Färber <afaerber@suse.de> |
efi_loader: Handle memory overflows 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>
|
#
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 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>
|
#
38ce65e1 |
|
30-Mar-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Always allocate the highest available address 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>
|
#
5d00995c |
|
03-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 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>
|